Aller au contenu principal

· 3 minutes de lecture
Etienne Rossignon

Finite State machines can be easily defined with the Sterfive opcua modeler.

@startuml
1022: Initializing
1024: Running
1026: Ended
1028: Interrupted
1030: Aborted
1030 --> 1022 : Aborted\nTo\nInitializing\nTransition
1026 --> 1022 : Ended\nTo\nInitializing\nTransition
1022 --> 1030 : Initializing\nTo\nAborted\nTransition
1022 --> 1024 : Initializing\nTo\nRunning\nTransition
1028 --> 1030 : Interrupted\nTo\nAborted\nTransition
1028 --> 1024 : Interrupted\nTo\nRunning\nTransition
1024 --> 1030 : Running\nTo\nAborted\nTransition
1024 --> 1026 : Running\nTo\nEnded\nTransition
1024 --> 1028 : Running\nTo\nInterrupted\nTransition
1024 --> 1024 : Running\nTo\nRunning\nTransition
@enduml
AttributeValue
BrowseName1:ProductionStateMachineType
IsAbstractNo
SubtypeOfFiniteStateMachineType
ReferenceNodeClassBrowseNameModellingRuleTypeDefinitionDataType
Components
HasComponentObject1:InitializingStateType
HasComponentObject1:RunningStateType
HasComponentObject1:EndedStateType
HasComponentObject1:InterruptedStateType
HasComponentObject1:AbortedStateType
HasComponentObject1:AbortedToInitializingTransitionTransitionType
HasComponentObject1:EndedToInitializingTransitionTransitionType
HasComponentObject1:InitializingToAbortedTransitionTransitionType
HasComponentObject1:InitializingToRunningTransitionTransitionType
HasComponentObject1:InterruptedToAbortedTransitionTransitionType
HasComponentObject1:InterruptedToRunningTransitionTransitionType
HasComponentObject1:RunningToAbortedTransitionTransitionType
HasComponentObject1:RunningToEndedTransitionTransitionType
HasComponentObject1:RunningToInterruptedTransitionTransitionType
HasComponentObject1:RunningToRunningTransitionTransitionType

States

BrowseNameReferencesTarget BrowseNameValueTarget Type DefinitionNotes
InitializingHasPropertyStateNumber0PropertyType
FromTransitionInitializingToAbortedTransitionTransitionType
FromTransitionInitializingToRunningTransitionTransitionType
ToTransitionAbortedToInitializingTransitionTransitionType
ToTransitionEndedToInitializingTransitionTransitionType
RunningHasPropertyStateNumber1PropertyType
FromTransitionRunningToAbortedTransitionTransitionType
FromTransitionRunningToEndedTransitionTransitionType
FromTransitionRunningToInterruptedTransitionTransitionType
FromTransitionRunningToRunningTransitionTransitionType
ToTransitionInitializingToRunningTransitionTransitionType
ToTransitionInterruptedToRunningTransitionTransitionType
ToTransitionRunningToRunningTransitionTransitionType
EndedHasPropertyStateNumber2PropertyType
FromTransitionEndedToInitializingTransitionTransitionType
ToTransitionRunningToEndedTransitionTransitionType
InterruptedHasPropertyStateNumber3PropertyType
FromTransitionInterruptedToAbortedTransitionTransitionType
FromTransitionInterruptedToRunningTransitionTransitionType
ToTransitionRunningToInterruptedTransitionTransitionType
AbortedHasPropertyStateNumber4PropertyType
FromTransitionAbortedToInitializingTransitionTransitionType
ToTransitionInitializingToAbortedTransitionTransitionType
ToTransitionInterruptedToAbortedTransitionTransitionType
ToTransitionRunningToAbortedTransitionTransitionType

· 3 minutes de lecture
Etienne Rossignon

Creating OPCUA models is a difficult task that requires a good understanding of the OPCUA modeling paradigms and good knowledge of conventions and best practices. Extending or creating a new ObjectType or DataType has always been tedious and time-consuming. Name each node right, and organize the nodes within the context of an existing companion specification is always challenging. Most of the time, this modeling exercise requires deep expertise in this field.

We also found that modeling tools need to play better regarding ease of use and simplicity and should integrate well with the revision control system to facilitate version tracking to allow diffing of two revisions of the same model, for instance.

There is no way one can maintain an OPC UA model file as the structure of the nodeset2.xml file, which is commonly used by all the OPC UA tool suites, is verbose and unmanageable by hand.

Looking around for a more modern Low Code approach, we decided to implement a tool for our internal needs. After all, Sterfive develops NodeOPCUA, and we have deep expertise in OPC UA Modeling, so we decided to incorporate our knowledge inside a dedicated modeling engine powered by NodeOPCUA.

We use a low-code approach with a few guiding principles in mind:

  • Human-readable: we use a text-based system with a friendly syntax in YAML Productivity and efficiency: we publish a JSON schema file that ensures the YAML file is correct and allows for intelli-sense support inside your IDE. On top of this, the modeler engine checks against many business rules and provides warnings and tips to let us improve the model.

  • Generate documentation and model: the YAML file contains not only the model definition but also all the documentation snippets in a rich markdown format for all the concepts we defined in the model. This allows us to keep the model definition and the associated documentation in a single source so they stay in sync. As the model files are generated, a documentation file that follows the convention of OPC UA companions specifications is also automatically created in one go. It contains automatically generated OPC UA class diagrams.

  • Minimalist: the definition file should have a clear and minimalist syntax with no redundancy. The modeling engine relies on business logic that interprets the design intent and takes the responsibility to extrapolate the underlying model by following the OPC UA design pattern and recommended best practices. Consequently, our model file requires 90% fewer lines than the equivalent nodeset2.xml file.

  • Comprehensive: we design the engine so complex models, including, InterfaceType, AddIns, MachineState, AlarmsType & EventType, can be easily defined.

  • Universal: the output model follows the nodeset2.xml format and is immediately reusable in any existing OPC UA toolchain, such as, for instance, and not limited to: Siemens TIA portal, BR Automation Studio, UAModeler, a home-brewed open-62541 server or a NodeOPCUA server, etc... making it convenient to design a new Companion Specification from scratch.

Sterfive has been using this tool for a while now in a professional context with customers, allowing us to improve it and craft it in the best possible way. We decided to go one step further and make it available to the OPC UA community of experts and modeling professionals. That is why we are pleased to share this tool with you now.