SPIE 2014 Wim Pessemier
SPIE 2014 Wim Pessemier
SPIE 2014 Wim Pessemier
lessons learned
Wim Pessemiera , Geert Deconinckb , Gert Raskina , Philippe Saeyc and Hans Van Winckela
a Institute
of Astronomy, KU Leuven, Leuven, Belgium;
b ESAT- dept. of Electrical Engineering, KU Leuven, Leuven, Belgium;
c E & A - Electrical Engineering, FET, KU Leuven - campus Gent, Gent, Belgium
ABSTRACT
Modern Programmable Logic Controllers (PLCs) have become an attractive platform for controlling real-time
aspects of astronomical telescopes and instruments due to their increased versatility, performance and standard-
ization. Likewise, vendor-neutral middleware technologies such as OPC Unified Architecture (OPC UA) have
recently demonstrated that they can greatly facilitate the integration of these industrial platforms into the overall
control system. Many practical questions arise, however, when building multi-tiered control systems that consist
of PLCs for low level control, and conventional software and platforms for higher level control. How should the
PLC software be structured, so that it can rely on well known programming paradigms on the one hand, and
be mapped to a well organized OPC UA interface on the other hand? Which programming languages of the
IEC 61131-3 standard closely match the problem domains of the abstraction levels within this structure? How
can the recent additions to the standard (such as the support for namespaces and object-oriented extensions)
facilitate a model based development approach? To what degree can our applications already take advantage of
the more advanced parts of the OPC UA standard, such as the high expressiveness of the semantic modeling
language that it defines, or the support for events, aggregation of data, automatic discovery, ... ? What are the
timing and concurrency problems to be expected for the higher level tiers of the control system due to the cyclic
execution of control and communication tasks by the PLCs? We try to answer these questions by demonstrating
a semantic state machine model that can readily be implemented using IEC 61131 and OPC UA. One that does
not aim to capture all possible states of a system, but rather one that attempts to organize the course-grained
structure and behaviour of a system. In this paper we focus on the intricacies of this seemingly simple task, and
on the lessons that we’ve learned during the development process of such a “PLC-friendly” state machine model.
Keywords: state machine, semantic modeling, PLC, OPC UA
1. INTRODUCTION
Over the last few decades, innovations in information technology have been re-shaping the landscape of indus-
trial automation systems significantly. Control systems have become more distributed, better integrated within
enterprise systems, can meet higher real-time demands, and have become more “open” as the suppliers con-
verge to programming and communication standards. In certain applications, the role of the PLC as a simple
“programmable logic controller” is now being taken over by so-called “PC-based” controllers, offering a more
versatile platform at the cost of increased complexity. This versatility is what makes the latter technology so
attractive: real-time control software can be written in more languages (not only standard IEC 61131-3 but also
C++ or Matlab/Simulink models for instance), the embedded operating system can run more applications (such
as communication servers, user interfaces, databases, ...), and one can take advantage of more recent hardware
innovations (such as multi-core architectures).
At the same time, it seems that information technology advancements will continue to push the boundaries
of conventional automation even further. Efforts such as Industrie 4.0 promise the dawn of “smart” factories,
consisting of cyber-physical systems that collaboratively control and optimize manufacturing processes in a
flexible way.1 The core ideas of Industrie 4.0 are all about integration, and they can be applied easily to
astronomical telescope facilities:
[email protected]
• end-to-end integration: an integrated development approach that encompasses several domains may
enable astronomers and engineers to deal with the complexity of future Extremely Large Telescopes;
• vertical integration: a departure from the traditional “three layered architecture” to a vertically inte-
grated architecture from the field level up to the facility level makes reconfiguration of the telescope and
instruments more flexible;
• horizontal integration: can assist decentralized control within a single facility (e.g. the telescope optics
coordinating with an instrument) or even across observatory boundaries (e.g. two telescopes collaborating
to optimize the available observation time).
Recent technologies such as PC-based controllers and OPC Unified Architecture play an important role in the
realization of the above ideas, because they narrow the gap between the traditional automation world and the
IT-world.2 Semantic modeling (or ontology engineering) is an additional discipline that can help to achieve these
goals. Applied to industrial applications, ontologies can uniquely identify (and organize, and even formally define)
all relevant parts and properties of a system, and link them together regardless of the engineering discipline they
belong to. This holistic idea of “semantic integration” is one way to achieve a tighter horizontal/vertical/end-to-
end integration as advocated by Industrie 4.0. Furthermore, because the semantics of the systems are formally
specified, it is possible to add logic or rules to the models in such a way that conclusions (or “inferences”) can be
drawn by software algorithms.3 This reasoning capability is what makes semantic applications “smart”.
At the Mercator telescope, we already developed a software infrastructure that can accommodate semantic
models of our instrumentation. In this paper however, we will focus on a particular ontology that we have
developed within our framework: one that allows us to model the states and behaviour of mechatronic systems.
We will show the technologies and tools that were used to develop the ontology, and how it can be used to model
control systems. We will then focus on how the state machine models can be converted into PLC software code,
the pitfalls we had to avoid, and the lessons we’ve learned throughout the development process.
An important remark is that Semantic Web technologies embrace the “Open World Assumption” or OWA.
This assumption says that any observation may be true unless it is explicitly stated to be false. Applied to our
use case, it means that we can only interpret the behaviour of a state machine by its known states and known
transitions. Consider for instance a state machine with two states called A and B, and a transition from A to B.
Based on this information, we cannot simply conclude that there is no transition from B to A. Only if we would
add the statement “B cannot transit to A” to our knowledge base, then we can infer that an active state change
from B to A would be invalid. In practice, this means that our state machine models do not have to be extensive
and “complete” descriptions: only the relevant knowledge must be modeled. More states and more transitions
can always be added later, without invalidating the original state machine model.
Inspired by the UML 2 (Unified Modeling Language version 2) concept of “protocol state machines”, we
have defined the concepts of fsm:ProtocolRegion and fsm:ProtocolStateMachine, as subclasses (according to
RDF-S semantics) of fsm:Region and fsm:StateMachine respectively. Instances of these concepts do not exhibit
behaviour, but instead they represent “abstract” regions and state machines that specify states and conditions
w.r.t. unspecified state variables. Non-protocol regions and state machines can be said to “conform” to their
counterpart via the fsm:conformsTo relation, which means that their states (and state variables and conditions)
correspond one-to-one to the protocol. The reason for defining protocol regions and state machines is re-usability:
all protocol definitions in the semantic model can easily be mapped to a software type (e.g. a Python class or
an IEC 61131-3 function block).
• fsm:Behaviour: something that has a fsm:Cause and an fsm:Effect, and optionally some time constraints.
• fsm:Cause: an expr:Expression, a fsm:State or a fsm:Transition that is causing some fsm:Behaviour.
In many situations, this simple “if-cause-then-effect” paradigm is useful to apply to our modeled systems. We
identify the following use cases:
†
In reality, many more causes (such as the motor load, the cooling provisions, the duty cycle, the safety factor used
by the manufacturer, ...) will influence the thermal behaviour of the particular motor. However, since we didn’t include
those causes in our model, they don’t participate in the modeled behaviour. Just like any other model, our semantic
model captures our interpretation of reality.
1. System analysis.
Consider the example of the electric motor running in overtemperature. Not only overspeeding may lead
to unacceptable temperatures, but also an engaged brake may have the same effect. The brake at its turn
may only be engaged (an effect) when the safety circuit is opened (a cause) or the power is lost (another
cause). This kind of causes and effects are very easy to represent by our ontology. The advantage is that
they can be analyzed, e.g. for troubleshooting purposes. A single query can answer a question such as
“What are all the known causes (even recursively) of a dangerous temperature of motor X?” or “What are
all the known effects (even recursively) of opening the safety circuit?”.
2. Code generation.
When the semantic state machine model represents a piece of software, causes and effects can easily be
mapped to an if-then construct by most software languages. As will be explained in the next section, we
have developed ontologies that can map state machines (including physical objects such as a motor) to
software models. Not only the states, regions, conditions etc. can be mapped to the software models,
but also the known behaviour. For instance, the software representation of our motor state machine can
implement the “overtemperature” behaviour as an if-then construct. As a result, the software representation
can generate a warning when it has detected an overspeed for at least two minutes.
As explained in another paper,7 even simple experimental setups are hard to model in an ontology editor
such as the one displayed in Fig. 1. Instead, we developed a software infrastructure that maps meta-model
ontologies to Domain Specific Languages (DSLs).7 The fsm ontology for instance will be mapped to a DSL
that has vocabulary terms such as fsm.State and fsm.hasRegion. Since the DSLs are based on CoffeeScript
(an approach successfully demonstrated by other projects8 ), a web development tool or a simple text editor is
sufficient to build models of setups like the one from our example. When the DSL scripts are executed, the
contents of the DSL files will be converted to a standard Semantic Web format, which can be stored in an
off-the-shelf knowledge base (see Fig. 3). An off-the-shelf template engine can now query the knowledge base
using SPARQL, the de-facto query language for the Semantic Web, to generate source code and documentation.
% #&
'(&
"# !
$
To get an idea of the appearance of our DSL scripts, we have included a few code samples in Appendix A. The
first sample shows a parametrized “macro” that can be used to model the sense of direction of a moving physical
system (such as a motor), as an orthogonal region. This orthogonal region is a recurring pattern, captured by the
DSL as a macro called MkDirectionRegion which we added to the csm or “common state machines” ontology.
We can use this and other macros to model the motor type of a supplier called “X”, as shown in Listing 3. The
x.MkMotor_Y macro can finally be used to instantiate a motor within the ontology of our experimental setup:
see Listing 4.
Note that the example provides some insight in how semantic models add “meaning” to the modeled entities.
For instance, the velocity instance created by the x.MkMotor_Y macro represents a velocity not because we
named it that way (which would be syntactic information), but instead because we modeled it as the velocity of a
geometrical transformation between two mechanical parts (which is semantic information). A “smart” application
could query a semantic model like this to learn for instance about all geometrical transformations between the
rotating parts of a telescope drive system. Based on this information, the application could conclude that a
motor speed of 1500 rpm corresponds to a telescope speed of 3◦ /sec, with both velocity vectors angled at 90◦ .
Developing ontologies that can express this kind of knowledge is a challenging task, but our first experiments
show that it is feasible with existing semantic web languages and rule languages such as SPIN.
2.5 Summary
In this section, we have demonstrated how control systems can be modeled using semantic languages. By
combining meta-models (such as the fsm ontology) with project-specific models (such as the setup1 ontology),
we can create a true “knowledge base”. The latter is essentially a database which stores not only all explicitly
modeled information of our system, but also the information that is implicitly present. The implicit knowledge
is the key to so-called “smart” applications: based on the explicit knowledge that we entered with our ontology
editor and our DSL scripts, an off-the-shelf reasoning software or rules engine can generate much more knowledge
about our modeled system. The result is a large knowledge base that can be analyzed for many different purposes
such as troubleshooting, code generation, verification, etc.
3. IMPLEMENTATION
3.1 Semantic models vs. software models
In the previous section, we have focused on the semantic models of physical objects such as electric motors.
What we haven’t explained yet is how the same semantic models can be used as the basis for software models.
Our methodology is to develop both kinds of models simultaneously, and link them together (all within the
DSL framework). This can be seen in Listing 4. The first 42 lines of code represent the semantic model of our
experimental setup, according to the DSL code of Listing 2 and 3. In contrast, onwards from line 44 the DSL
description is only about software modeling: it represents software objects as instances of soft:Instance, linked
together by soft:hasAttribute relations. For each physical object on the first lines, there is a corresponding
software instance on the last lines. Both are tied together via the soft:models relation.
In practice, it would take a lot of effort to map all properties of physical objects manually to attributes
of software objects. Fortunately however, most of the knowledge needed to perform this mapping is already
present in our semantic models. What’s still needed is a formalism, i.e. a set of rules that unambiguously
generate software models based on the semantics of physical object models. Such a rule is shown in Listing 1: it
constructs a new software instance for each orthogonal region of a state machine. Similar rules can be created
to construct software attributes for each state of an orthogonal region, for each condition of a state, etc. The
generated software models are thus “implicit” knowledge of our models, as they are generated automatically by
a rules engine. The result is one big coherent knowledge base that now also links the software properties to the
other (electrical, mechanical, ...) properties of a control system.
1 CONSTRUCT {
2 ?newSoftwareInstance rdf:type soft:Instance .
3 ?newSoftwareInstance soft:models ?region .
4 ?newSoftwareInstance rdfs:label ?regionName .
5 }
6 WHERE {
7 ?stm fsm:hasRegion ?region
8 ?region rdfs:label ?regionName .
9
10 FILTER NOT EXISTS { ?software soft:models ?region . } .
11
12 BIND (xsd:string(smf:currentBaseURI()) AS ?currentBaseURI) .
13 BIND (spif:buildURI("{?currentBaseURI}#{?regionName}-model") AS ?newSoftwareInstance) .
14 }
Listing 1. SPARQL query to construct a software instance for all orthogonal regions of a model.
As we’ve learned, many of the intricacies of IEC 61131-3 (and PLC systems in general) come to the surface
when trying to find a suitable PSM that meets the above requirements. Below we list some of the lessons that
we’ve learned throughout the development process.
Lesson 1. The third edition of IEC 61131-3 facilitates a model-driven development approach.
In our model-driven architecture, we are generating code (based on the state machine models and fundamental
behaviour), and glue that code together with custom developed code (that typically serves as low-level behavioural
code). Several software patterns can accommodate this kind of “mixing”. One of them is the “visitor pattern”,9
which we’ve used in the past11 and which does not depend on object-oriented features that were absent in
the original IEC 61131-3 standard. Now that object-oriented features have been added to the standard, we
can apply the “template method pattern”,9 which lets subclasses override methods that can be called by the
superclass. In our case, the superclasses correspond to the generated code that represent the modeled state
machines, orthogonal regions, states etc. The subclasses on the other hand must be coded manually by the
developers who are responsible for the low-level behaviour.
The PSM representing the software switch of our example is shown in Fig. 4. We experimented with several
other patterns too, but none of those attempts offered significant added value. For instance, interfaces (i.e. pure
abstract classes) could force developers to implement certain behaviour of our state machines, but they exclude
other patterns because non-pure abstract classes and multiple inheritance are not supported by IEC 61131-3.
'
.
.
5+ 6"% "%&
! 6+
07 )) '3 8, 4 .
+# +
07 )) '3 "*4 .
+ %9!
/ ! ! 69"$.
Figure 4. IEC 61131-3 model of the software switch of the example used throughout the paper.
The approach of Fig. 4 turned out to be much more convenient than the approach based on the visitor
pattern that we applied in earlier projects. The resulting code is much cleaner and its behaviour is easier to
comprehend since the generated code and the custom code are tightly bound together. It is our goal to create
a library (namespace) of frequently needed function blocks and corresponding user interface widgets, and re-use
that library in several projects.
Lesson 2. OPC UA can extend a model-based development approach down to the plant floor level.
First of all, we’d like to emphasize that OPC UA is able to capture the same knowledge as our DSL scripts.
OPC UA is essentially a semantic language, based on very similar principles as the RDF standard of the Semantic
Web community. This means that any model we develop using the infrastructure of Fig. 3 can be represented
“natively” by an OPC UA server. There’s no need for a mapping or a conversion, i.e. both our DSL scripts and
OPC UA interfaces can represent the same graph with the same nodes, the same URIs, the same links, ...
In case of PLCs, the OPC UA address space is not freely programmable. Instead, most PLC vendors
support the PLCopen companion standard of OPC UA that defines a semantic model of the IEC 61131-3
standard. This companion standard is nothing more than a “meta-model” ontology that defines classes such as
iec61131:CtrlFunctionBlockType and predicates such as iec61131:HasInputVars. Using this ontology, any PLC
program loaded on a PLC can be exposed automatically by an OPC UA server. This means that the platform
specific models of subsection 3.2 can be used not only for generating software code, but also for interfacing OPC
UA clients and servers. Figure 4 thus represents not only the software running on the PLC, but also the OPC
UA interface exposed by that PLC.
In previous experiments we had been developing graphical PLC software models and PIM-to-PSM trans-
formations in a proprietary Computer Aided Software Engineering (CASE) tool.11 By adding an additional
semantic layer (previously called “meta-model” ontologies) on top of the PIM, it becomes much easier to link our
software models to other (electrical, mechanical, ...) engineering aspects of our project, and to existing ontologies
such as the PLCopen one.
Lesson 3. Support for the more advanced parts of the OPC UA standard is growing ... but is still limited.
Compared to the “classic” OPC standard, OPC UA is still a very young technology with a comparatively
small installed base. From the developers point of view, OPC UA is also more complex, even though third-party
toolkits or our own open-source framework try to overcome this problem.12 All of this may explain why most
commercial OPC UA servers and clients currently only support the features that were already offered by the
former OPC standard: reading and writing variables, browsing an address space, and monitoring data changes.
Alarms, events and historical data are additional services that a few vendors have already implemented in their
products. In case of our state machine implementation, we can send events for instance whenever the active
state of an orthogonal region changes.
What we’ve learned is that despite the efforts of some companies, there remains a big gap between what the
OPC UA standard provides, and what is (commercially) available already right now. We feel that OPC UA
has the potential to shift existing paradigms towards more decentralization and better (semantic) integration...
but currently the implementation lags behind. One example is the support for OPC UA method calling on
PLCs. As explained further on, this service can be a very “elegant” way to vertically integrate PLCs up to the
level of Service Oriented Architectures (SOA). Even if the first supplier will soon release an OPC UA server
that supports this feature, it will most likely take some time before SCADA (Supervisory Control And Data
Acquisition) software companies provide support in their OPC UA clients. Another example is the OPC UA
query service. Finding the right information in a complex address space appears to be a very valuable feature of
a semantic technology such as OPC UA, yet we don’t know any server that actually implemented this service.
Lesson 4. PLCs are no longer “closed” platforms due to standard exchange formats.
In previous applications, we have been generating code using a template engine that produced IEC 61131-3
compliant Structured Text (ST) output in plain text files.11 The programming environment of our PLC supplier
could import those files, even though the exchange format was not standardized. In our new framework however
we have migrated to a standard encoding format: we now export XML (eXtensible Markup Language) code that
conforms to the schema published by the PLCopen organization. This XML schema is well documented and has
become a mainstream exchange format supported by many suppliers in the automation industry. Since most of
our generated code is structural (e.g. function block declarations), the produced XML code is uncomplicated. For
the few lines of code that make up the implementation part of the function blocks, we generate structured text
(ST) since text based languages are less cumbersome to generate than graphical languages. To our knowledge
there is no standard XML schema yet of the third edition of IEC 61131-3, so currently a vendor-specific schema
must be used instead for describing methods, inheritance, interfaces etc.
As the generated code is fully separated from the custom code, no language choice is imposed on the developers
who provide the custom implementations. In practice however, we mostly rely on:
• Sequential Function Chart (SFC) to implement “slow” cyclic low-level behaviour (such as cyclic polling of
serial devices);
• Structured Text (ST) to implement algorithms that do not involve the invocation of complex function
blocks (such as mathematical algorithms);
• Ladder Diagram (LD) to implement boolean logic (which may involve the invocation of complex function
blocks, such as motion control);
• Continuous Function Chart (CFC) to implement continuous processes (such as feedback control loops).
Lesson 5. PLCs can be deployed in service oriented architectures, if synchronization problems are dealt with.
A characteristic feature of PLCs is their cyclic operation, as shown in Fig. 5. It can be seen that the
execution of the PLC program and the communication to external devices are separated in time, which can lead
to unpredictable behaviour when multiple clients initiate the communication simultaneously. Consider a PLC
program that increments an integer whenever a boolean variable is “true”. What happens if the value of the
trigger is written twice during the (very short) time span between two program executions? Will the integer be
incremented twice, or will the PLC program never “notice” that the trigger has been updated twice? Another
problem may occur when multiple variables need to be written consecutively. For instance, a motion control
application may expose a “MoveAbsolute” function block instance that exposes variables to set the setpoint
velocity, the setpoint acceleration and a trigger. What happens if two clients start to write these variables at the
same time? Is it possible that the two requests are “mangled”, so the motion is started with the wrong settings
(e.g. the velocity setpoint of the first client and the acceleration setpoint of the second client)?
# $
!"
The problems just described are essentially synchronization problems: several threads of execution require
access to the same resources. In the IT world, problems like these are usually solved with mutexes. To our
knowledge however, no such mechanism exists for our particular use case. A plausible explanation is that
synchronization problems like these are very unlikely to occur in typical industrial PLC-based systems: cycle
times are very small, the number of clients is very limited, and concurrent write requests to the PLC variables are
very rare. Nevertheless, we strongly prefer to exclude all risk by using a recent innovation by our PLC supplier:
the so-called “SOA PLC” or “Service Oriented Architecture PLC” by Beckhoff Automation. By exposing function
block methods (a new object-oriented feature of IEC 61131-3) in the OPC UA address space of the PLC, remote
clients can now invoke procedures directly on the PLC.10 We believe that this seemingly small technical feature
is a very important one: in one call the client can now provide input to the server, the server can react on
that input and can notify the client of the result. Since all communication requests are serialized (i.e. they are
handled by a single thread of execution), the calls are atomic. This means that no synchronization problems can
occur, and that PLCs can now safely be deployed in a service oriented architecture. Another advantage is that a
single method call replaces several read and write requests between client and server, which increases efficiency.
At the time of writing, the new feature was not commercially available yet but we were allowed to test a bèta
version of the new software, and we hope to deploy a first application at our telescope site during the summer
of 2014.
4. CONCLUSIONS
In this paper we have presented a new methodology for developing state machine models that can be implemented
on PLCs. By developing a meta-model for representing finite state machines based on Semantic Web technology,
we have rooted our semantic models in formal logic. Thus, our state machine ontology allows us to formally
specify the states, orthogonal regions, transitions etc. of our modeled systems, but also to reason about this
knowledge and to infer more knowledge. This reasoning mechanism can be exploited to convert the state machine
models into platform independent software models.
In the second part of the paper we show how those platform independent models can be mapped into
platform specific models, again based on formalisms that we can define within our “ontology-based” software
infrastructure. Our target platform is an IEC 61131-3 compliant soft-PLC that hosts an OPC UA server. Using
a small experimental setup as an example, we demonstrate how the object-oriented features of IEC 61131-
3 and companion standards of OPC UA facilitate a model-driven development approach. We also reflect on
the availability and maturity of OPC UA implementations, and on the suitability of IEC 61131-3 w.r.t. code
generation. Finally we identify the synchronization problems that may occur when PLCs are integrated in a
service oriented architecture, and report a way to avoid those problems.
REFERENCES
[1] Kagermann, H., Wahlster, W. and Helbig, J., “Recommendations for implementing the strategic initiative
INDUSTRIE 4.0 - Final report of the Industrie 4.0 Working Group,” Acatech, München, 19-26 (2013).
[2] OPC Foundation, “OPC Unified Architecture, Pioneer of the 4th industrial (r)evolution,” OPC Foundation,
Scottsdale AZ, (2014).
[3] Allemang, D. and Hendler, J., [Semantic Web for the Working Ontologist], Morgan Kaufmann, Waltham
MA, (2011).
[4] Smethurst, M., Styles, R. and Scott, T., “The Places Ontology,” 27 November 2010,
<http://vocab.org/places/schema.html> (26 May 2014).
[5] Berners-Lee, T., Hendler, J., “The Semantic web,” Scientific American Magazine, May 17 (2001).
[6] Knublauch, H., Hendler, A. J. and Idehen, K., “SPIN - W3C Member Submission,” 22 February 2011,
<http://www.w3.org/Submission/spin-overview/> (26 May 2014).
[7] Pessemier, W., Raskin, G. Van Winckel, H., Deconinck, G. and Saey, P., “A practical approach to ontology-
enabled control systems for astronomical instrumentation,” Proc. ICALEPCS 2013, (2013).
[8] Filgueira, J. M., Bec, M., Soto, J., Lio, N. and Peng, C. Y.,“GMT software and controls overview,” Proc.
SPIE 8451, 845111 (2012).
[9] Gamma, E., Helm, R., Johnson, R. and Vlissides, J., [Design Patterns: Elements of Reusable Object-Oriented
Software], Addison-Wesley, 325-344 (1995).
[10] Hoppe, S., “SOA enabled PLC: Remote Service execution into the IEC61131-3 controller,” OPC Day Europe
2014, Esslingen, (14 May 2014).
[11] Pessemier, W., Deconinck, G., Raskin, G., Saey, P. and Van Winckel, H., “Design and First Commissioning
Results of PLC-based Control Systems at the Mercator Telescope,” Proc. SPIE 8451, 84512V (2012).
[12] Pessemier, W., Deconinck, G., Raskin, G., Saey, P. and Van Winckel, H., “UAF: a generic OPC Unified
Architecture Framework,” Proc. SPIE 8451, 84510P (2012).
APPENDIX A. EXAMPLE
models/common/statemachines.coffee (excerpt)
1 # create the model that will capture commonly used state machines:
2 MODEL "http://mercator.iac.es/onto/models/common/statemachines" : "csm"
3
4 # import the (meta)models:
5 csm.IMPORT expr # meta-model: expressions
6 csm.IMPORT fsm # meta-model: finite state machines
7
8 # add a macro to create an orthogonal region for the direction of a moving system:
9 csm.ADD fsm.Region "MkDirectionRegion" : (ref, tolerance) -> [
10 INIT $ # initialize the internal stack
11
12 # identify the state variable dependencies (they will be linked to the states by the rules in the fsm ontology!):
13 fsm.hasDependency fsm.MkStateVariable(type: expr.Double, initial: 0.0, assign: ref) "ref"
14 fsm.hasDependency fsm.MkStateVariable(type: expr.Double, initial: 0.0, assign: tolerance) "tolerance"
15
16 # add the states:
17 fsm.hasState fsm.State "forward" : [ fsm.hasCondition GT( $.ref, $.tolerance ) ] # ref > tolerance
18 fsm.hasState fsm.State "reverse" : [ fsm.hasCondition LT( $.ref, NEG($.tolerance) ) ] # ref < -tolerance
19 fsm.hasState fsm.State "standstill" : [ fsm.hasCondition NOT( OR( PATH( $.forward, fsm.hasCondition ),
20 PATH( $.reverse, fsm.hasCondition ) ) ) ]
21 ]
models/suppliers/x.coffee (excerpt)