IoT versus SCADA/DCS Data Acquisition Patterns


The term Internet of Things (IoT) is used in a variety of contexts where it is often misunderstood, because it can be replaced by other terms much better describing the matter we deal with or the definitions are not compliant with each other. Let me remind you about the very beginning of this term life.

That ‘Internet of Things’ Thing

The phrase “Internet of Things” started its life as the title of a presentation made in 1999 and aimed at explaining a new idea of radio frequency identification (RFID) in the context of the supply chain performance. It is clear that it doesn’t mean that someone has any right to control how others use the phrase, but my point is that a precise term definition is important for working together on: common rules, architecture, solutions, requirements, capabilities, limitations, etc. In practice having a common definition it is possible to check a selected technology, solution or product capabilities against requirements of the application entitled to use this term.

The main goal of this article is to contribute to the community work aimed to distinguish the IoT applications domain features. The main challenge faced up is to narrow the definition to make it unambiguous and meaningful.

In most publications I know the term IoT can be simply replaced with the following well-known terms:

  • SCADA – Supervisory Control and Data Acquisition
  • DCS – Distributed Control Systems

and the text still will be perfectly OK. In this context the “sensor” term plays the role of the “thing” and the nodes network is a synonym of the Internet. No one usually takes care whether we are talking about the temperature sensor in a bedroom or in a boiler drum in a power plant except that in case of a power plant sometimes the prefix Industrial is added. To make our life easier let’s forget about the “I” (Industrial) prefix at all because it doesn’t change the most important application domain features.

To illustrate the further discussion let me provide examples that can be recognized as SCADA/DCS and IoT applications respectively.

SCADA/DCS example

Let’s assume that an OPC UA Server exposes 123456 values representing the crude oil refining process. Using SCADA on top of this server we can monitor and manually control the process. Using DCS it is possible to implement a supervisory control algorithm to provide macro optimization.

For this scenario we can apply the following work-flow:

  • The server instantiates an OPC UA Information Model for the crude oil refining process.
  • All plant floor devices equipped with sensors are fetching data representing the current process state (for example the flow meter #A-4321 supporting the Modbus RTU communication protocol) and are waiting for data requests coming from the server communication engine.
  • The communication engine embedded in the server polls all plant floor devices including the flow meter #A-4321 to recover the current process state.
  • Finally, the OPC UA Server exposes the data (updates value attributes of the relevant variable nodes, e.g. #A-4321 object representing the virtual flow meter #A-4321) in his Address Space Management component (i.e. in the Address Space instantiated according to the Information Model of the crude oil refining process).
  • OPC UA Clients connected to this server are updated in a standardized way.

Note in this scenario that the OPC UA Client and OPC UA Server can establish connection over the Internet using any existing transport protocol, e.g. HTTP, HTTPS, TCP, UDP, AMQP. Selection of the transport protocol between the client and server is negotiated and limited by the OPC UA specification. To get more read OPC Unified Architecture – Main Technological Features.

You can use the server I have exposed many years ago to test this scenario. The instruction how to connect is included in the following document:

IoT example

Do you think a box (or even pack) of cigarettes could be the “thing”. It has a bar-code, so it is the source of data. Is it the sensor – NO because the bar-code reader (industrial scanner) is the sensor in this case. Can we recognize the bar-code reader as the “thing” – again the answer is NO if the goal is to provide a GLOBAL cigarettes tracking system. The same applies to drugs for example. Is it an IoT solution – my answer is YES, no doubts. Is it SCADA/DCS –the answer is NO, because the server (undelaying communication engine) cannot poll all possible places spread over the world where the box could appear. There are two reasons:

  • It is impractical or even impossible to manage such a huge set of addresses.
  • The server doesn’t know when to poll because the relevant data appear as an event instead of a process state value.

Assuming that the server is interested or even allowed to collect product data of one vendor only – not all codes fetched by any bar-code reader are relevant to the server.

Is the “thing” smart – I don’t think we can call the bar-code something smart. Is it controllable – NO.

The most interesting observation is that we can recognize this use case as an IoT application, but we have not mentioned OPC, AMQP, MQTT, SOA, Internet, WI-FI, wireless, Modbus, etc. at all, but only that we have important mobile data and the solution is globally scoped. It is good because we can check the available technology capabilities against this application requirements. As I have said selected communication technology is not the goal, but we must know how it scales to applications like this.

Now, let’s replace the word GLOBAL by LOCAL (for example cash desks farm in a shop) and the same application is no longer an IoT deployment, isn’t it? It is true even if the cash desks are interconnected using the IP protocol (e.g. Intranet)!

Sometimes it is stressed that any IoT application must guarantee a high level of robustness, but importance of the sensor and data robustness requirement is applicable to many kind of applications, e.g. controlling an airplane engine during flight. The same engine could be monitored and tracked after landing in any airport using the local WI-FI by uploading archival data to a central advanced analytic system (like the cigarettes box bar-code). Is it IoT? It isn’t during the flight, but the solution is life sensitive. After landing it is IoT, but the reliability of the data and data transfer is not so important, isn’t it?

IoT Paradigms

My proposal of the Internet of Things definition is as follows:

Internet of Things is all about:

  • mobile data fetching – how to gather the data from mobile devices (things);
  • mobile data subscription – how to transfer the data over the Internet to a place where it could be processed;
  • mobile data processing – how to integrate the data into a selected application to improve process behavioral performance.

Data fetching is related to a variety of last mile communication technologies, for example RFID, WI-FI, VHF, Bluetooth, etc. Subscription could be supported using messaging systems, e.g. AMQP, MQTT, etc. A good candidate for leveraging data consumption is for example OPC Unified Architecture.

Referring to previous examples, the data fetching process looks very similar in both cases – we have a data source and a sensor coupled together at some point in time responsible for sampling the data. Analyzing the examples from the application functionality point of view we cannot compare them because there are no requirements defined at all – only very general descriptions are provided. It looks like application capabilities are not relevant to the term definition. It is the reason why the terms SCADA, DCS and IoT are used interchangeably neglecting the fundamental differences between the following data acquisition patterns:

  • Data polling–continuous checking of the sensors to see what state they are in, usually in multipoint or multidrop communication (a communication engine with multiple devices attached that share the same line) by sending a message to each device, one at a time, asking each to respond and send new data.
  • Data subscription– senders of messages containing the process data fetched by the sensor, called publishers, do not prepare the messages to be sent directly to specific receivers, called subscribers, but instead they categorize published messages into topics without knowledge of which subscribers, if any, may receive the message. Similarly, subscribers express interest in one or more topics and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

It is worth stressing that in both cases reusability of the fetched data is assured. In data polling scenario the server coupled with the communication engine may be connected to by many clients at the same time. In data subscription scenario the publisher is responsible for multicasting the data to all attached subscribers directly or indirectly using a broker.

To deploy the IoT scenario:

  • the mobile data must be sent over the Internet (or Intranet) using messages;
  • the payload of these messages is consumed asynchronously by a server (e.g. OPC UA Server) responsible for exposing it in an address space;
  • the applications (e.g. OPC UA client) process the exposed data to reach selected key performance indicators (KPI).

It is required that the messages payload is formatted in a standardized way to be factored on the fetching site and meaningfully consumed by the analytic application (e.g. OPC UA client).

Data Acquisition patterns

In the above discussion the application functionality has been excluded as a factor, which can be used to recognize IoT applications. Now let’s analyze the impact of the data acquisition pattern on the application behavioral model.

Using data polling we must deal with the synchronous data acquisition pattern. In this case the application must follow the interactive behavioral model, because it actively polls the data source for more information by pulling data from a sequence that represents the process state in time. Such behavior is represented by an iterator, which is used to iterate through a data stream. The application is active in the data retrieval process – it controls the pace of the retrieval by sending the request messages at its own convenience. This enumeration pattern is synchronous, which means that the application might be blocked while polling the data source. Such polling pattern is similar to visiting the books shop and checking out a book. After you are done with the book, you pay another visit to check out another one. If the book is not available you must wait, but you may read what you selected.

On the other hand, in the reactive behavioral model, the application is offered more information by subscribing to a data stream, and any update is handed to it from the source. The application is passive in the data retrieval process: apart from subscribing to the source data stream, it does not actively poll the source, but merely react to the data being pushed to it. In this case, the application will not be blocked by waiting for the source to update. This is the push pattern employed by IoT. It is similar to joining a books club in which you register your interest in a particular genre, and books that match your interest are automatically sent to you as they are published. You do not need to wait but you must read what you get. Employing a push pattern is helpful in many scenarios, especially if data is available asynchronously as events.

The push model implemented by IoT requires additional resources responsible for multicasting the pushed data to all subscribers. This functionality may be accomplished by a middleware fulfilling the broker role or supported by the network infrastructure, e.g. IP multicast.

The fundamental differences between the interactive and reactive behavioral model must obviously impact the final application functionality, for example:

  • process controllability;
  • data destination discoverability;
  • maintainability.

Using data polling the request message may also contain data to control the state of a selected actuator. In this case the response message usually contains positive or negative acknowledge that can be used by the application as a condition selecting further activity. For example in case of communication disruption the request message may be resent. In case of actuator failure an alarm may be raised. In case of the pushing data scenario it is hard to implement remote control functionality in a similar way because the communication path is like a one-way route.


In interactive behavioral model the communication engine must have all information including addressing in advance to properly prepare request messages. The messages must be self-contained to be used by the network routing mechanism. In case of reactive behavioral model the application doesn’t know the source of data in advance. Therefore the sensors responsibility is to format the message and push it to an appropriate distribution channel. In this case the messages are not self-contained, because the information carried by them is only indirectly used by the routing mechanism.

For the polling data scenario configuration modification may be required after replacing the sensor if the data sources are not isomorphic for the data acquisition process. On the other hand the pushing data scenario requires that any replacement or modification of the data source must not need any modification of the application configuration.


From the above discussion we can derive the following dependency models:

Interactive applications (e.g. SCADA, DCS):
  • The application engine depends on the synchronous data acquisition engine – data is observed as a stream of entities.
  • The acquisition engine depends on the process devices (sensors or actuators), which it must know in advance.
Reactive applications (e.g. IoT):
  • The application engine depends on the asynchronous data acquisition engine – data is observed as a stream of events.
  • The data source depends on the data distribution channel.
  • The asynchronous acquisition engine depends on the distribution channel.
  • The data source and acquisition engine are associated by the data distribution channel proprietary mechanism.

There is a well suited open source project to start prototyping with this scenario.


OPC UA Makes Highly Distributed Network Control Systems Possible


Nowadays, to be on edge, modern manufacturing automation systems have to be involved. Usually they consist of numerous different IT systems located at business management/operation and process control levels. It is broad class of applications domain where business IT and control systems are converged to make a large whole with the aim to improve performance as the result of the macro optimization and synergy effect. This domain is called Industrial IT. Frequently the systems are distributed geographically in multi-division organizations.

To deploy the mentioned above convergence the systems have to be integrated – must interoperate with each other. From integration we should expect improved performance as a result of synergy and macro optimization effects.

After integration the systems should make up a consistent system, i.e. each subsystem (as a component) must communicate with each others. The final information architecture is strongly dependent on organization, culture, type of technology and target process. Communication is necessary for exchanging data for production state analysis, operation actions scheduling, supervisory control and task synchronization in the process as a large whole.

Vast majority of enterprises declare that difficulties with the integration of the existing systems are the most important obstacle to expand the process control and business management support. Other major integration problems are diversification of the existing systems, their quantity and non-unified data architecture.

Integration process results in Large Scale Distributed Network Control Systems (LSDNCS). Systems belonging to this class are usually created in a multi-step integration process. To succeed, the process has to be governed by a well-defined information and communication architecture.

Integration Models

System integration means necessity of the information exchange. To exchange information we need an association between components. Going further, to instantiate association, i.e. to make the component interoperable, we need at the same time a common:

  • information representation –  a language (data type),
  • underlying communication infrastructure – a transport (protocol + medium),

We must be aware that establishing an association we are actually building information architecture – system structure. It is worth stressing that selection of the architecture development has a great impact on the final robustness, maintainability, expandability, dependability, functionality, and last but not least implementation costs.

Generally we have three possibilities:

Peer to peer approach: Common integration practice is to achieve short-term ad-hoc objectives by manually creating/proprietary dedicated point-to-point links between the subsystems everywhere it is useful (see fig. 1). Using randomly this approach we can establish numerous independent links ((k+n)(n+k-1)/2 where k, n – number of business and process control components appropriately). The number rapidly grows, e.g. it is equal 1770 links for n=10 ; k=50, and finally we have to deal with rapidly growing complexity leading to the communication chaos, which is difficult to be maintained.

In this model the information and communication architectures are closely coupled. This approach is very popular, but adversely affects all of the solution features.

Peer to peer approach

Fig. 1

Totalitarian approach: One option to overcome the communication chaos problem is to use an “all in one” product dedicated to both functions: process control and business management (see presentation). Usually, it is provided as one complex, total system – let’s call it a supper-system. Most of the MES (Manufacturing Execution System) vendors offer theirs products as a panacea for all problems of the chaotic system integration.

Actually supper-system does not solve the problem, it only hides it under a not transparent cover and makes the solution very difficult to expand and vendor related forever.

In this model the system distribution is reduced, and as a consequence many associations can be instantiated on the same platform without necessity to communicate. This model reduces complexity by reducing communication needs.

If strictly observed it could be a dead end.

Process Observer approach: The Process Observer is a consistent, homogenous real-time representation of the process control layer. It is a kind of the virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface (see presentation). It allows sharing data from plant floor devices by the process and business management systems, using international standards of data exchange. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.

Thereby, the structure of the links becomes systematic and the existing functionality of the upper layers is preserved. Now, they can gather the process data in a unified, standardized way (see fig.2).

Using the Process Observer archetype the number of links between components can be substantially reduced and, what is very important is a linear function of the number of nodes.

Process Observer model greatly reduces the whole complexity and decrease dependency by decoupling application associations and underlying communication routes. Additionally, it allows applying systematic design methodology and building information architecture independently of underlying communication infrastructure.

Fig. 2

Fig. 2

Related articles

Real-Time Communication for Large Scale Distributed Control Systems (Proceedings of the International Multiconference on Computer Science and Information Technology pp. 849–859 ISSN 1896-7094)

Process and business layers robust integration (white paper)

Communication management in the Process Observer Archetype (Proceedings of the 16th conference “Polish Teletraffic Symposium 2009”)

Large Scale Distributed Process and Business Management Integration (Proceedings of the 14th International Congress of Cybernetics and Systems of WOSC)

OPC Unified Architecture: Enabler of Future Solutions


Talking about acceptance and adoption of OPC Unified Architecture we usually focused on uniqueness and remarkable features of this standard with the goal of sending the message: “OPC UA is the best interoperability standard – it is much better then other classic solutions ever available” to the community.  Additionally, we are sending (circulating) this message over and over to other members of our close OPC UA community. My concern is if it is an effective approach because it looks like “the old shoes syndrome” – it is not enough to buy new ones only because there are much better new ones. We should rather say “don’t use your old shoes while jumping onto your windsurfing board only because they are comfortable – it is not very sensible”. On the grounds of my personal experience I am trying to imagine new unexplored yet fields of potential applications of the OPC UA. It is obvious that their number is uncountable, therefore a selection key must be applied. To follow the idea from the introduction above the “ENABLER” seems to be most appropriate to flag the technology, solution, application, model, approach, etc. that OPC UA makes possible.

The Exploration Catalog

To make my dreaming more useful for others, my first attempt is to prepare a series of short articles (a catalog) on new application scopes where OPC UA could be recognized as a prerequisite. All of them have a common title pattern “OPC UA Makes it Possible”. Today the catalog consists of:

  • OPC UA Makes Process Observer Archetype Possible: Process Observer is a kind of a virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface. It allows the process and business management systems, using international standards of data exchange to share data from plant floor devices. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.
  • OPC UA Makes Complex Data Access Possible: The Industrial IT domain is an integrated set of ICT systems. System integration means the necessity of the information exchange between them (the nodes of a common domain). ICT systems are recognized as a typical measure of processing information. The main challenge of deploying an Industrial IT solution is that information is abstract – it is knowledge describing a situation in the selected environment, e.g. temperature in a boiler, a car speed, an account balance, etc. Unfortunately machines cannot be used to process abstraction. It is also impossible to transfer abstraction from one place to another.
  • OPC UA Makes Highly Distributed Network Control Systems Possible: Nowadays, modern manufacturing automation systems have to be involved. Usually they consist of numerous different IT systems located at business management/operation and process control levels. To deploy the convergence the systems have to be integrated – must interoperate with each other. From integration we should expect improved performance as a result of synergy and macro optimization effects.
  • OPC UA Makes Global Security Possible: We can observe rapid development of globally scoped applications for domains like health, banking, safety, etc. The globalization process is also observed in control engineering. The secure transfer of process control data over the Internet must, therefore, be addressed as the most important prerequisite of this kind of applications.
  • OPC UA Makes Cloud Computing Possible: Cloud Computing is defined as a method to provide requested functionality as a set of services. Following the Cloud Computing idea and offering control systems as a service, there is required a mechanism created on the service concept and supported abstraction and virtualization – two main pillars of the Cloud Computing paradigm.
  • OPC UA Makes Smart Factory Possible: In this case  “collaboration” is the key word. Analyzing the collaboration needs of the smart factory we must distinguish two dissimilar targets surrounding the factory: humans and applications. To make this collaboration well-defined in the information exchange and behavioral aspects, the collaboration platforms (e.g. SharePoint) and integration measures (OPC UA) must be integrated.
  • OPC UA Makes Smart User Interface Possible: It introduces a concept of semantic HMI that is an approach to relay the interface on discovering the meaning of process data using the metadata provided by plant floor measurement and control devices. Additionally, network-connected HMI needs special security precautions to be applied.
  • OPC UA Makes Production Traceability Possible: To use analyzers and track selected product and its ingredients parameters, complex data must be managed, i.e. created, transmitted, processed, and saved. To be useful, process data must be exposed in the context of well know semantics represented by the metadata.
  • OPC UA Makes Smart Utility Distribution Systems Possible: Following the concept of smart grids, more and more companies decide to start working on smart utility distribution systems (gas, water, chilly water, or even oil) to improve the performance and availability. The process is dispersed geographically and partially managed by independent operators. An active role of ultimate consumer is very important.

All the articles above are OPC UA related. For those looking for more information about this interoperability standard there are two articles providing very basic information, I hope, helping to follow the main topics.

  • OPC UA – Specifications: OPC Unified Architecture is described in a layered set of specifications issued by the OPC Foundation, that are broken into parts. It is purposely described in abstract terms and only in selected parts coupled (mapped) to existing technology on which software can be built. This layering is intentional and helps isolate changes in OPC UA from changes in the technology used to implement it.
  • OPC Unified Architecture: Main Technological Features: It focuses on new features of this interoperability standard including: service oriented architecture, object-oriented information model, abstraction and mapping, security, profiles, robustness.

Looking for the new application scope of OPC UA we must face up to managing team work aimed at exploring new undiscovered areas. On the grounds of experience gained while managing variety of innovative process control and business management projects I can say that their scope definition and budget estimation is always the most challenging task. Typically, if the estimated budget of any project is higher than the other ones, the solution provider is recognized as inefficient in one way or another. But there might be another reason if innovative projects are concerned, i.e. the provider’s know-how and extraordinary experience make a better assessment possible. Better always means higher in this context, so typically it puts the solution provider in an underprivileged position and leads to the “more stupid the better” issue. For an innovative project, the main reason why its critical parameters are hardly predictable is its innovative nature. From the definition, an innovation as a translation of an idea or invention into a product or service that creates value is an exploration into unexplored areas. The leader of the team must, therefore, face up to a high level of uncertainty. The following article provides some insights and a proposal with the goal of mitigating this issue.

  • Embedding Agile Principles as Contract Rules: It proposes a methodology framework that tightly couples agile management (to dynamically control the work scope and time framework) to workload tracking with the goal of maximizing the value for money.


To bring the presented ideas into solutions, more work is required with the aim of preparing comprehensive guidance collecting all that is needed to help deploy them in a real environment. Before trying to figure out what should be done to step forward, the audience of the outcome must be determined. Thus we should address the following needs:

  • For end users – adding solutions to requirements, but limited to feasible ones only
  • For integrators – adding solutions to portfolio, but limited to confirmed ones only
  • For vendors – adding features to products, but limited to required ones only

To create a foundation supporting deployment of the technology in new areas, the effort should be focused on:

  • Feasibilities studies: aimed at describing architecture (re-usable templates) as an interconnection of products making up a structure, product features required to interconnect them in a consistent way, business processes surrounding the solution in question, cost estimation, and solution profitability.
  • Pilot applications: aimed at providing proof of concept and “how to …” cookbook.
  • Best practice guidance: to maintain the quality and minimize application risks.

All the activities on the wish list above require an appropriate business model to happen, but this topic is outside this article scope. Good news is that governments and European Union support innovative projects in some countries, e.g. Poland, making the research and development much cheaper (up to 85% might be refunded). Since the beginning of the financial perspective 2007-2013, Poland has become the largest recipient of support under Cohesion Policy in the history of the European Union. In the financial perspective 2014-2020 the support is expected to be even greater. There are many programs planned with small and medium-sized enterprises as main targets with the priority focused among others on:

  • Research and development of modern technologies
  •  R&D infrastructure
  • Capital for innovation
  • Investments in innovative undertakings
  • Diffusion of innovation
  • Polish economy on the international market

Do not miss this opportunity – you will be welcomed to Poland.

OPC UA Makes Smart Factory Possible

From the historical perspective some key words can be recognized as mile stones of the manufacturing enhancement process. These key words describe the main solution or concept that is specific for consecutives eras of development. So the following words hit the big time in history: microprocessor system, automatic processing (PLC), and redundant high availability solution. Today, to be in fashion, we must provide smart solutions, and finally almost everything is smart. We have smart-cars, smart-grids, smart-buildings, and smart-cities. Therefore we must ask, if it is only a buzzword. Going further: can we imagine smart cigarettes? To be honest, I must say that today we do not need artificial intelligence to smoke things like that, but recently I have learnt that cigarettes may have a button to change their flavor on demand – it seems that we are very close to a keyboard concept. What’s more, today it is required that cigarettes are digitally signed to be traceable – it seems that we are very close to the RFID technology and, finally, the Internet of Things concept. Anyway, giving a right answer to this question is only a matter of the definition of the word smart, but nowadays production of cigarettes, as almost everything, is doubtless a challenging activity and needs a steady improvement of the manufacturing environment to compete successfully on the global market.

Read the story: Smart Factory Deployment Strategy

Smart Factory Deployment Strategy

Related articles

OPC UA Makes Cloud Computing Possible.

For someone accomplishing hundreds of control system projects it is not easy to accept the fact that we have adopted most innovative solutions from business technology. Unfortunately, first a programmable calculator was produced and later after that the programmable controller (PLC) appears, first the personal computer (PC) was used to prepare invoices, and later after that SCADA was deployed on the PC. This post is about adoption of the Cloud Computing concept by the process control industry and requirements that must be fulfilled to apply safely this concept.

The cloud concept becomes more and more popular in the – we call them disdainfully – office suit, but more officially business management applications. Maybe it also could be widely adopted and will give us new arm to further improve manufacturing efficiency index including cost reduction and improve availability of utilities.

Applications are traditionally classified as:

  • Business management
  • Process management

Customers Relationship Management (CMS) is a business management application, but controlling a process using PLC is an example of process management. As a rule we do not try to discover relations and possibility to integrate functionality of applications like that. It is like a myth – they have nothing in common – that’s all. Really? Writing this sentence a concept of Smart Grid comes immediately into my mind, where optimization of energy consumption is located mainly on the customers’ site – energy consumers.

The above example is used to illustrate as the highly distributed measurement environment can be offered as a service.

Cloud Computing is defined as a method to provide a requested functionality as a set of services. There are many examples that cloud computing is really useful to reduce cost and increase robustness. Following the Cloud Computing idea and offering control systems as a service it is required a mechanism created on the service concept and supported abstraction and virtualization – two main pillars of the Cloud Computing paradigm.

In my opinion, it can be obtained as the result of set up this mechanism on the foundation of OPC Unified Architecture (see also OPC Unified Architecture – Main Technological Features) that is out of the box solution derived from the Service Orient Architecture principles. Therefore we can say that it is service centric solution.

Thanks to OPC UA standard we are able to abstract the process control as the OPC UA Address Space implementing selected, process oriented information model. Address Space is very useful to offer selective availability, as a means to manage the process representation and scope of its exposition to the users – OPC UA Clients.

In Cloud Computing concept the virtualization is recognized as possibility to share the services by many users. OPC UA server is a publishing mechanism exposing process data and meta-data to unlimited number of clients, and therefore it fulfills this requirement as well.

Multiuser dynamic and global environment causes a risk of unauthorized access and concerns about how cloud reliability and security could threaten manufacturing stability. Because OPC UA engages public key infrastructure – the strongest widely used authentication mechanism – the process can be protected against any cyber attack.

All the above lead to the sentence that process control community is well equipped to adopt the Cloud Computing and take advantage of new features that open new fields of applications. The only open question is if the process control community is ready to put trust on the new emerging technology.

See also:

Embedding Agile Principles as Contract Rules

Agile management is recognized as a methodology that helps us to guide software development projects towards the most valuable outcome possible. The methodology well accommodates inevitable unpredictability of the project that adversely affects the expected results and workload assessment. It is, therefore, a good candidate to be applied to high risk innovative research projects based on a contract. Methodology extension and tools based on the business processes modeling are proposed with the aim of harmonizing and embedding agile principles as contract rules.

This proposal is based on the experience gained while managing variety of innovative process control and business management projects. For these and similar projects, their scope definition and budget estimation in advance have always been the most challenging task. Typically, if the estimated budget of any project is higher than the other ones, the solution provider is recognized as inefficient in one way or another. But there might be another reason if innovative projects are concerned, i.e. the provider’s know-how and extraordinary experience make a better assessment possible. Better always means higher in this context and, in a typical bid where budget is the most important factor, it puts the solution provider in an underprivileged position and leads to the “more stupid the better” syndrome.
For an innovative project, the main reason why its critical parameters are hardly predictable is its innovative nature. From the definition, an innovation as a translation of an idea or invention into a product or service that creates value is an exploration into unexplored areas. The leader of the team must, therefore, face up to a high level of uncertainty.

The main aim of any invention result application is to further satisfy the needs and improve selected processes. But in all cases it is a business process involving at least two organizations: a customer and a solution provider that must cooperate under a contractual relationship, i.e. a voluntary, deliberate, and legally binding agreement between them. The contractual relationship is evidenced by an offer, an acceptance thereof, and a valid (legal and valuable) consideration.

To make the procurement process transparent, fix-price and fix-term offers are usually expected to simplify the comparison and selection of a bid for contract award. As a consequence, the quantitative nature of the comparison relaxes the responsibility of the target company (customer) management involved in the selection process, which makes the selection process offer centric and neglects uncertainty of the proposed terms. In some circumstances it could cause an assessment of just a “wish list”, but not a realistic proposal and leads to circular impossibilities:

  •  It is impossible for the customer to prepare the specifications because it is unaware of the necessity of exploration.
  • It is impossible for the solution provider to prepare the offer as the specifications are inadequate and the unanswered questions can be addressed and worked out as project goals only.

The procurement issues described above could be partially solved using direct negotiations or the single-source acquisition method. Unfortunately, both “suffer from” the qualitative nature of the selection process and usually are an exception to the typical procedure. Nevertheless, as the quantitative assessment is difficult or even impossible, they might be a better choice.
The discussion about the procurement process is out of this post scope. However, in spite of the selected procurement method, the question how to limit the budget, determine the time frame and define the expected scope and quality in the contract is still open.

A new methodology is required to address this question. Its implementation should be non-invasive and effortless but, if strictly observed, it must control the development process to minimize the price-to-performance factor and assure meeting of the customer basic requirements.

For the problem described above, I propose a methodology framework that tightly couples:

  • Agile management to dynamically control the work scope and time framework.
  • Workload tracking to precisely control the value for money.

This method is also proposed to be deployed using supporting tools developed on the process model basis to make the deployment straightforward.

To get access to the full text document contact me at:
Mariusz Postół Ph. D.
Institute of Information Technology
Lodz University of Technology