Engineering Platforms

Domain-specific engineering platforms are developed specifically to mitigate the engineering challenges by providing: [1]

It makes the synthesis of such processes to the design of corresponding control software transparent and automated [2].

  • • Usage of Model-Driven Engineering, to eliminate manual coding by auto synthesizing implementations and their testing and simulators.
  • • Continuous monitoring of the behaviour of the control software against its intended design during its operation, to detect anomalies across multiple maintenance and evolution cycles.

Domain-Specific Engineering Platform Architecture

Figure 13.4.

Domain Knowledge Repositories

Knowledge is at the heart of cognitive control. The knowledge repository includes relevant domain knowledge, knowledge about the particular plant system, its components and operating environment, knowledge about desired behavioural outcomes, and contextual knowledge about behaviour of the deployed devices and the plant system in their operating environment. The challenge is to create structured representations of all this information as a knowledge repository, that can be used by the DSEE platform and other tools.

Knowledge about entities, such as devices and how they organize into subsystems and an overall system, can be expressed using semantic web technologies such as Resource Description Framework (RDF), as shown in Figure 13.5. A key idea is that we need to capture information, not only about entities, their properties and their relationships to other entities, but also about the capabilities that they provide. A capability description identifies


Domain-specific engineering platform usage workflow


Use of Semantic Web Technologies to capture domain knowledge

the function performed by an entity, associated features (add-on and variant functionality, including security and safety features), as well as the service interfaces for using the capability, and associated quality characteristics (performance, availability, etc.) and resource dependencies. Capability descriptions permit selection, among alternative resources and devices, to find one that meets the particular contextual needs. The set of entities and associated characteristics is specific to each domain, so we must build a domain knowledge repository of concepts and entities of interest in that domain. The model includes not only concepts relating to the plant system, but also those pertaining to the environment of the plant system, e.g., a warehouse operations system would include a description of warehouse concepts, including its physical layout.

In addition to capturing the characteristics of the entities, we need to also capture the process patterns involved in achieving goals and outcomes. This involves the description of procedures and algorithms, so it is best expressed in a language. Since the procedures operate on domain objects, ideally the language should be specific to that particular domain. The domain-specific languages (DSLs) described in the next section are the ideal vehicle with which to capture the process patterns in the domain.

Finally, we also need structured representations of behaviour, including the insights resulting from analytics. Whereas monitoring produces streams of time-series data, we need a way to capture the knowledge encapsulated in those time series in a compact form. We can describe behaviour in terms of a collection of observable elements (inputs/outputs, flows, states, properties, structure, events, interactions) and the relationships among them. For example, transactions and physical laws define relationships among inputs, states and outputs. The response time of a module can be captured in terms of a range of values associated with the "response time" property. We can create similar specifications of the arrival rates of inputs, the variety of possible values for a given input, constraints on legal combinations of values for multiple outputs etc. Insights from analytics can now also be expressed as relationships among observable elements. It should be noted that the vocabulary of observable elements is domain specific and is part of the collection of concepts captured in the RDF model.

The above schema, for creating structured representations of entities and concepts, processes and behaviour, provides the mechanisms needed for the knowledge repository:

  • • Domain knowledge is captured in terms of a domain vocabulary of entities and concepts in RDF, process patterns expressed using DSLs, and behavioural knowledge about expected relationships among observable elements.
  • • Plant system and environment knowledge is expressed as a system model, defined over the RDF entities and vocabulary, and associated properties and behavioural relationships (for the behaviour of the environment).
  • • Desired behavioural outcomes are expressed as behavioural relationships over the properties in the RDF model.
  • • Contextual knowledge about the observed plant system behaviour is expressed as behavioural relationships over the properties of the devices and subsystems in the plant system model.

Thus, we can create a knowledge repository that expresses all the information and knowledge relating to the plant system in a uniform domain-specific structured representation.

Domain-Specific Languages: Raising Engineering Specifications to the Level of Knowledge

Currently, control software and control system solutions are implemented by engineers in a patchwork of technologies, including languages, such as Java and C++, PLC tools, DCS packages, SCADA packages and auxiliary tools and technologies including loggers, archives, alarm handling tools, databases, presentation tools, etc. Whereas each individual tool improves productivity and provides powerful capabilities, there is no integrated view of the overall solution (except in the engineers' minds). The operational model of the control system cannot readily be extracted from this patchwork.

In contrast, from the domain point of view, the operational model of any controller is pretty straightforward. Whereas particular continuous control algorithms, situation detection modules and decision modules may encapsulate complex logic within them, the overall discrete control logic is relatively straightforward, implementing well-known patterns in the domain for orchestrating behaviour, achieving particular functional and quality outcomes, and handling various situations.

The take-home message is that it is highly desirable to express the operational model for the control system in domain-specific terms, where the patterns involved would be immediately clear. Figure 13.6 shows an example of a DSL for the control systems domain (which is useful to express the operational logic of device and subsystem controllers), whereas Figure 13.7 shows an example of a DSL for expressing business workflows in the warehouse operations domain; such DSLs are needed in the DCS layer.

Model-Driven Engineering: Automated Generation of Life Cycle Artefacts

Once the desired behaviour is expressed using these DSLs, implementations in various technologies can be automatically generated from these descriptions. In effect, we are raising the level of solution engineering from the


Control systems DSL (M&C ML)


Domain-specific language for expressing task workflow

implementation technology level to the domain knowledge level. This has huge impacts on life cycle costs. Moreover, because the operational model is expressed in the same terms as the domain knowledge, it becomes possible to automatically synthesize parts of the operational model by combining the requisite patterns from the domain knowledge and selecting the appropriate resources to provide the required capabilities for performing the tasks involved in the patterns.

If the right information is present in the domain knowledge repository and in the DSL- specification of the operational model of controllers, it is possible to automatically generate simulations of devices and subsystems and to automate verification.

For hardware devices, if the associated behavioural specifications capture their responses to particular inputs (both in terms of state changes and outputs), then that can be used to build stub simulations of hardware devices. For controllers, DSL specifications include both their control (parent) interfaces and their interfaces with child devices or controllers (and peer interfaces, if any). If there are behavioural specifications of partner system behaviour associated with those interfaces, or if there are detailed operational model specifications available for the partner systems, those specifications can be used to generate driver implementations corresponding to the parent controller, and stubs for the other interfaces. Thus, it is possible to automatically generate simulators, both for individual devices and for the plant system as a whole, from the knowledge repository and operational model specifications.

If the behavioural specifications identify the space of values for each input (and valid combinations), and, ideally, if those inputs are grouped into equivalence classes, it is possible to automatically generate verification cases that run the devices or plant systems through large numbers of scenarios, and to verify whether the plant system meets the desired outcome specifications.

In short, as we increasingly capture knowledge about the plant system, its environment, and relevant domain knowledge in structured form, it will become possible to achieve increasingly higher levels of automation of the entire engineering life cycle, even in the presence of intelligent system elements and features, such as learning. With the combination of behaviour envelopes and automated simulation and verification, plus Digital Twins to learn the actual contextual behaviour of the plant system, it might even be possible to achieve higher levels of reliability than with the current paradigm.

Continuous Monitoring and Digital Twins

Control systems engineering includes not only the specification of actions to be taken by the control system, but also how the physical system is expected to respond to these actions. In other words, the engineering of plant systems includes expectations of how the controlled plant system will behave in different situations - it is this identification of target behaviour that drives the entire engineering process.

By including these specifications of expectations as part of the engineering, we can generate tools that monitor the actual behaviour of the system, compare it with these expectations, and flag deviations for refinement of the engineering model. Continuous monitoring is an offline approach for this, that analyzes log files and monitoring data against expected behaviour, and flags deviations for analysis by engineers.

Digital Twins are part of the actual operational environment, and operate in parallel with the plant system, observing the streams of monitoring data and building/refining models of system behaviour. Digital Twins can be used for predictive analysis.

  • [1] A standard platform to design and develop control systems, following standard control software architecture patterns, which needs tobe contextualized only for different complex cyber physical systems.Hence, it eliminates the need to reinvent architecture and the designof control software from scratch for every system. • Use of domain-specific languages (DSL) and Controlled NaturalLanguages (CNL), raising the levels of abstraction for specifying thedesign of control systems. This ensures that the design of the variousparts of the control software is created using a standard language,ensuring uniformity in the usage of concepts and vocabularies fromthe domain of interest. It eliminates the possibility of any inconsistencies in the control software design, created across distributedteams. • Explicating domain knowledge to domain-knowledge repositories.Such domain knowledge can be reused and composed by domainspecialists and systems architects to come up with process definitions that a complex cyber physical system should implement.
< Prev   CONTENTS   Source   Next >