Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "BaSyx / Documentation / API / ControlComponentProfiles"

m (Facet Category Values: Distinguish between alternativ and combinable facets in facet categories.)
m (ES Facets: Added proper MTP bit number mapping.)
 
(9 intermediate revisions by the same user not shown)
Line 10: Line 10:
  
 
== Profiles ==
 
== Profiles ==
 
 
[[File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|thumb|An example control component in OPC UA realizing different facets.]]
 
[[File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|thumb|An example control component in OPC UA realizing different facets.]]
<!-- TODO add more examples -->
+
<!-- TODO change to an example with BASYS profile -->
<!-- TODO maybe move examples to "Implementation" page? -->
+
<!-- TODO add more examples to "Implementation" page -->
 
A profile is a composition of facets from different facet categories.
 
A profile is a composition of facets from different facet categories.
 
For example a control component profile can be defined by the following facets.
 
For example a control component profile can be defined by the following facets.
Line 23: Line 22:
 
The address space of a control component in OPC UA conforming to this profile is shown in the [[:File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|figure]].
 
The address space of a control component in OPC UA conforming to this profile is shown in the [[:File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|figure]].
  
Facets ordered in different facet categories may describe a huge variety of control component realizations.
+
Facets ordered in different facet categories may describe a huge variety of control component realizations.  
 
Consequently, profiles are needed to reduce the amount of facet combinations to a usefull subset.  
 
Consequently, profiles are needed to reduce the amount of facet combinations to a usefull subset.  
The profiles are not defined right now, as this is part of the ongoing BaSys 4.2 project.
+
Examples of control component dummies in OPC UA can be found in the [[https://git.rwth-aachen.de/acplt/basys4.2/ccProfilesUA| ccProfilesUA project]].
<!-- BaSys 4.2 D-4.4 Integrationsvarianten -->
+
 
 +
=== Profile Definition ===
 +
<!-- BaSys 4.2 D-4.7 Integrationsvarianten -->
 
Every profile will refer to at least one facet from every facet category and will therefore be considered as full featured profile.
 
Every profile will refer to at least one facet from every facet category and will therefore be considered as full featured profile.
At first some important profiles may be defined in the future:
+
Hence, applications can be developed and implemented against single facet values or whole profiles.
* BaSys4.0 - Control components as used in the BaSys 4.0 project
+
The following profiles are currently defined and may be extended in the future:
* BaSys4.2 - Control components conform to the BaSys 4.2 project
+
 
* MTP - Control components that are NAMUR MTP conform
+
*; MINIMAL : Minimal requirements for the component and service interface. May be used for the integration of sensors.  
* PACKML - Control components that are conform to PackML
+
 
<!-- TODO Add EMF metamodell of tests
+
*; BASYS : Default profile for control components conform to the BaSys 4.2 project. Used in BaSys demonstrators.
 +
 
 +
*; FULL : Maximum features of the control component with all interfaces available.
 +
 
 +
*; PACKML : Control components that are fully compatible to PackML.
 +
 
 +
*; MTP : Control components that are described and conform to NAMUR Module-Type-Package (MTP).
 +
 
 +
The following table defines the described profiles by referencing according [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#Facets|facet values]].
 +
As different standards like PackML allow for variations themselves (e.g. availability of SEMIAUTO execution mode), only minimal requirements are set.
 +
 
 +
{| class="wikitable" style="background-color:#D2DEEF;"
 +
|- style="background-color:#5B9BD5;"
 +
! Profile
 +
! Service Interface (SI)
 +
! Occupation (OC)
 +
! Execution Modes (EM)
 +
! Execution States (ES)
 +
! Operation Modes (OM)
 +
|-
 +
| MINIMAL
 +
| 1
 +
| 1
 +
| 1
 +
| style="background-color:#C5E0B4;" | 1
 +
| style="background-color:#C5E0B4;" | 1
 +
|- style="background-color:#EAEFF7;"
 +
| BASYS
 +
| 4
 +
| 6
 +
| 6
 +
| style="background-color:#E2F0D9;" | 2
 +
| style="background-color:#E2F0D9;" | 2
 +
|-
 +
| FULL
 +
| 62
 +
| 14
 +
| 30
 +
| style="background-color:#C5E0B4;" | 3
 +
| style="background-color:#C5E0B4;" | 3
 +
|- style="background-color:#EAEFF7;"
 +
| PACKML
 +
| 32
 +
| 1
 +
| 6
 +
| style="background-color:#E2F0D9;" | 3
 +
| style="background-color:#E2F0D9;" | 1
 +
|-
 +
| MTP
 +
| 16
 +
| 1
 +
| 6
 +
| style="background-color:#C5E0B4;" | 5
 +
| style="background-color:#C5E0B4;" | 3
 +
|}
 +
 
 +
==== BASYS Default Profile ====
 +
The default profile for BaSys control components has an OPERATIONS service interface, conform to [[BaSyx_/_Documentation_/_API_/_ControlComponent#Virtual_Automation_Bus_.28VAB.29_implementation|VAB Implementation]].
 +
It has a simple occupation state machine with one priorytized state (OCCUPIED, PRIO) and no local overwrite.
 +
Moreover, at least the MANUAL and AUTO execution mode must be available.
 +
As execution state machine a subset of PackML and ISA88 exuction states are selected.
 +
Multiple operation modes may be available, but only one operation mode is active at a time and needs to be selected beforehand.
 +
 
 +
=== Profile Interface Specification ===
 +
In order to describe the variant and its features, respectively the profile, of a control component an [[BaSyx_/_Documentation_/_ControlComponentProfiles#Interface_Specification|interface specification]] is given here.
 +
It may be used in type or instance descriptions, e.g. in AAS submodels, or even in the control component itself.
 +
A self description of control components is an important feature to enable plug and produce scenarios.
 +
{| class="wikitable"
 +
! Parent !! Name !! Type !! Rule !! Property Datatype !! Property Values
 +
|-
 +
|  || PROFILE || Property Group || Optional ||  ||
 +
|-
 +
| PROFILE || SI || Property || Optional || String || [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#SI_Facets|SI Facets]]
 +
|-
 +
| PROFILE || OC || Property || Optional || String || [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#OC_Facets|OC Facets]]
 +
|-
 +
| PROFILE || EM || Property || Optional || String || [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#EM_Facets|EM Facets]]
 +
|-
 +
| PROFILE || ES || Property || Optional || String || [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#ES_Facets|ES Facets]]
 +
|-
 +
| PROFILE || OM || Property || Optional || String || [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#OM_Facets|OM Facets]]
 +
|}
 +
 
 
=== Profile Compliance Testing ===
 
=== Profile Compliance Testing ===
Describe test setup and terms (test cases, fixtures, suites, environment)
+
Compliance tests need to be defined in order to verify that a control component conforms to a profile or specific facets.
-->
+
These tests can be static, checking the interface according to the interface specifications in the [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#SI_Facets|SI Facets]].
 +
Moreover, behavioural tests can be defined based on the standardized state machines.
 +
These test may be even be used to explore the profile of an unknown control component, which could be used in a plug and produce procedure for example.
 +
 
 +
An implementation and description for test cases and example dummies in OPC UA utilizing the Google-Test framework can be found [[https://git.rwth-aachen.de/acplt/basys4.2/ccProfilesUA#profile-compliance-testing| ccProfilesUA project]].
 +
<!--TODO write an own subsection in "Implementation" page-->
  
 
== Facet Categories ==
 
== Facet Categories ==
Line 85: Line 173:
  
 
== Facets ==
 
== Facets ==
 +
 +
The following table shows an overview of all facet values. The left (blue) part are combineable values realized as bitmasks, the right (green) part are alternative single values.
 +
{| class="wikitable" style="background-color:#D2DEEF;"
 +
|- style="background-color:#5B9BD5;"
 +
! Bit / Value
 +
! Service Interface (SI)
 +
! Occupation (OC)
 +
! Execution Modes (EM)
 +
! Value
 +
! Execution States (ES)
 +
! Operation Modes (OM)
 +
|- style="text-align:center;"
 +
| style="text-align:left;" | 0 / 0
 +
| colspan="3" | UNKNOW
 +
| style="background-color:#C5E0B4; text-align:left;" | 0
 +
| colspan="2" style="background-color:#C5E0B4;" | UNKNOWN
 +
|- style="text-align:center; background-color:#EAEFF7;"
 +
| style="text-align:left;" | 1 / 1
 +
| colspan="3" | NONE
 +
| style="background-color:#E2F0D9; text-align:left;" | 1
 +
| colspan="2" style="background-color:#E2F0D9;" | NONE
 +
|-
 +
| 2 / 2
 +
| CMD
 +
| OCCUPIED
 +
| AUTO
 +
| style="background-color:#C5E0B4;" | 2
 +
| style="background-color:#C5E0B4;" | BASYS
 +
| style="background-color:#C5E0B4;" | MULTI
 +
|- style="background-color:#EAEFF7;"
 +
| 3 / 4
 +
| OPERATIONS
 +
| PRIO
 +
| MANUAL
 +
| style="background-color:#E2F0D9;" | 3
 +
| style="background-color:#E2F0D9;" | PACKML
 +
| style="background-color:#E2F0D9;" | PARALLEL
 +
|-
 +
| 4 / 8
 +
| SERVICES
 +
| LOCAL
 +
| SEMIAUTO
 +
| style="background-color:#C5E0B4;" | 4
 +
| style="background-color:#C5E0B4;" | ISA88
 +
| style="background-color:#C5E0B4;" | CONTI
 +
|- style="background-color:#EAEFF7;"
 +
| 5 / 16
 +
| MTP
 +
|
 +
| SIMULATE
 +
| style="background-color:#E2F0D9;" | 5
 +
| style="background-color:#E2F0D9;" | MTP
 +
| style="background-color:#E2F0D9;" |
 +
|-
 +
| 6 / 32
 +
| PACKML
 +
|
 +
|
 +
| style="background-color:#C5E0B4;" | 6
 +
| style="background-color:#C5E0B4;" | OPCUA
 +
| style="background-color:#C5E0B4;" |
 +
|- style="background-color:#EAEFF7;"
 +
| 7 / 64
 +
|
 +
|
 +
|
 +
| style="background-color:#E2F0D9;" | 7
 +
| style="background-color:#E2F0D9;" | NE160
 +
| style="background-color:#E2F0D9;" |
 +
|}
 +
  
 
=== SI Facets ===
 
=== SI Facets ===
 
<!-- BaSys 4.2 Deliverable D-3.2 -->
 
<!-- BaSys 4.2 Deliverable D-3.2 -->
  
The [[BaSyx_/_Documentation_/_API_/_ControlComponent#Control component interface|control component service interface]] '''E1''' may be realised in various ways.
+
The [[BaSyx_/_Documentation_/_API_/_ControlComponent#Control component interface|control component service interface]] ''E1'' may be realised in various ways.
 
Basys classifies different realisations via facets from the SI facet category.
 
Basys classifies different realisations via facets from the SI facet category.
 
The service interface category ('''SI''') describes how a control component can be affected by the means of orchestration and how the resulting state changes may be observed.
 
The service interface category ('''SI''') describes how a control component can be affected by the means of orchestration and how the resulting state changes may be observed.
Line 118: Line 277:
 
| A string variable called CMD (command input) with a specific syntax is used to activate service operations
 
| A string variable called CMD (command input) with a specific syntax is used to activate service operations
 
| A flat list of variables of all aggregated component states under a containing element (folder)
 
| A flat list of variables of all aggregated component states under a containing element (folder)
| Process control applications with IEC 61131
+
| Process control applications with IEC 61131<ref name="Grothoff2019CMDInterface">Grothoff, J et al (2019) Komponentenbasierte Automatisierung: Realisierung einer flexiblen Schnittstelle zur Auftragsorientierten Prozessführung in IEC 61131-3 Umgebungen, AUTOMATION 20219, Baden-Baden</ref>
 
|-
 
|-
 
| 3|| 4
 
| 3|| 4
Line 140: Line 299:
 
Note on ''NAMUR Module Type Package (MTP)'': in the future, basys will map the description for the orchestration of modules that are described via a NAMUR MTP to facets or even to a profile.
 
Note on ''NAMUR Module Type Package (MTP)'': in the future, basys will map the description for the orchestration of modules that are described via a NAMUR MTP to facets or even to a profile.
 
Therefore an existing facets like VARIABLES may be used or a new facet may be necessary.
 
Therefore an existing facets like VARIABLES may be used or a new facet may be necessary.
<!-- TODO Describe (important) facets in detail:
+
 
 
==== SI Facet CMD ====
 
==== SI Facet CMD ====
 +
[[File:BaSyx-ControlComponent-Example-OPCUA-SI-CMD.png|thumb|An example control component in OPC UA realizing the CMD service interface.]]
 +
The SI facet CMD determins a control component with a command interface, based on <ref name="Wagner2015CMDInterface">Wagner, C. & Epple, U. (2015) Sprechende Kommandos als Grundlage moderner Prozessführungsschnittstellen, AUTOMATION 2015, Baden-Baden</ref>.
 +
The command interface consists of at least one string variable called the command input or CMD, that uses the following syntax:
 +
 +
<nowiki><Sender>;<Order>;[<Parameter1=Value1>,<Parameter2=Value2>,<...>]</nowiki>
 +
 +
[[BaSyx_/_Documentation_/_ControlComponentProfiles#Interface_Specification|Interface specification]] for facet CMD (All specifications: [[File:BaSyx-ControlComponentProfiles-Interface_Specification-xls.zip]]):
 +
<!--TODO add excel file and link-->
 +
{| class="wikitable"
 +
! Parent !! Name !! Type !! Rule !! Facets !! Property Datatype !! Property Values !! Property Writeable
 +
|-
 +
|  || CMD || Property || Mandatory || SI==2 || String || [sender];[order];[param1=value1,...] || Writeable
 +
|-
 +
|  || CMDLAST || Property || Optional || SI==2 || String || [last accepted command] ||
 +
|-
 +
|  || CMDOLIST || Property || Optional || SI==2 || String[] || [list of supported orders] ||
 +
|-
 +
|  || CMDOPREF || Property || Optional || SI==2 || String[] || [list of required parameters for each order] ||
 +
|-
 +
|  || STATUS || Property Group || Mandatory || SI==2 ||  ||  ||
 +
|-
 +
| STATUS || ER || Property || Mandatory || SI==2 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Error_state_state_machine|Error States]] ||
 +
|-
 +
| STATUS || ERLAST || Property || Optional || SI==2 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Error_state_state_machine|Error States]] ||
 +
|-
 +
| STATUS || WORKST || Property || Mandatory || SI==2 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Work_state_state_machine|Work States]] ||
 +
|-
 +
| STATUS || OCCST || Property || Mandatory || SI==2 && OC > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Occupation_state_machine|Occupation States]] ||
 +
|-
 +
| STATUS || OCCUPIER || Property || Mandatory || SI==2 && OC > 1 || String || [occupier id] ||
 +
|-
 +
| STATUS || OCCLAST || Property || Optional || SI==2 && OC > 1 || String || [id of last occupier] ||
 +
|-
 +
| STATUS || EXMODE || Property || Mandatory || SI==2 && EM > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution_mode_state_machine|Execution Modes]] ||
 +
|-
 +
| STATUS || EXST || Property || Mandatory || SI==2 && ES > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution_state_state_machine|Execution States]] ||
 +
|-
 +
| STATUS || OPMODE || Property || Mandatory || SI==2 && OM > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Operation_Mode_state_machine|Operation Modes]] ||
 +
|}
 +
 +
Some major advantages of this facet are:
 +
* The CMD variable is a single endpoint for orders. So an (atomic) write operation is sufficient to for every order including parameter setting.
 +
* The CMD input is easy to use and implement in different technologies, as only the transfer of a string is necessary.
 +
** The control component can process the command asynchrounus in its own cycletime.
 +
** No operations are needed. Some technologies or embedded devices (especially PLCs) do not provide invokation or remote procedure call functionality.
 +
* The control component does an implicit type conversion for parameters, so no user side browsing for exact types and casting is necessary.
 +
* Parameters may even be written separately, before sending an command, if they are realised as own variables. This is usefull for default parameters or if different sources are responsible for different parameters.
 +
* A batch of commandos is easily human readable.
  
 
==== SI Facet OPERATIONS ====
 
==== SI Facet OPERATIONS ====
 +
[[File:BaSyx-ControlComponent-Example-OPCUA-SI-OPERATIONS.png|thumb|An example control component in OPC UA realizing the OPERATIONS service interface.]]
 +
The SI facet OPERATIONS determines a control component service interface with a flat list of operations.
 +
Operation names are equal to the order names in the command input.
 +
Hence, a operation call corresponds to a command request.
  
 +
[[BaSyx_/_Documentation_/_ControlComponentProfiles#Interface_Specification|Interface specification]] for facet OPERATIONS (All specifications: [[File:BaSyx-ControlComponentProfiles-Interface_Specification-xls.zip]]):
 +
<!--Table was generated from Interface specification xls by: https://tools.wmflabs.org/excel2wiki -->
 +
{| class="wikitable"
 +
! Parent !! Name !! Type !! Rule !! Facets !! Property Datatype !! Property Values
 +
|-
 +
|  || OPERATIONS || Property || Mandatory || SI==4 || Map ||
 +
|-
 +
| OPERATIONS || FREE || Operation || Mandatory || SI==4 && OC&(2&#124;4) ||  ||
 +
|-
 +
| OPERATIONS || OCCUPY || Operation || Mandatory || SI==4 && OC&2 ||  ||
 +
|-
 +
| OPERATIONS || PRIO || Operation || Mandatory || SI==4 && OC&4 ||  ||
 +
|-
 +
| OPERATIONS || AUTO || Operation || Mandatory || SI==4 && EM > 1 ||  ||
 +
|-
 +
| OPERATIONS || MANUAL || Operation || Mandatory || SI==4 && EM&2 ||  ||
 +
|-
 +
| OPERATIONS || SEMIAUTO || Operation || Mandatory || SI==4 && EM&4 ||  ||
 +
|-
 +
| OPERATIONS || SIMULATE || Operation || Mandatory || SI==4 && EM&8 ||  ||
 +
|-
 +
| OPERATIONS || START || Operation || Mandatory || SI==4 && ES > 1 ||  ||
 +
|-
 +
| OPERATIONS || STOP || Operation || Mandatory || SI==4 && ES > 1&& ES!=7 ||  ||
 +
|-
 +
| OPERATIONS || RESET || Operation || Mandatory || SI==4 && ES > 1&& ES!=7 ||  ||
 +
|-
 +
| OPERATIONS || ABORT || Operation || Mandatory || SI==4 && ES > 1&& ES!=6 ||  ||
 +
|-
 +
| OPERATIONS || CLEAR || Operation || Mandatory || SI==4 && ES > 1&& ES!=6 ||  ||
 +
|-
 +
| OPERATIONS || HOLD || Operation || Mandatory || SI==4 && ES > 2&& ES!=6 ||  ||
 +
|-
 +
| OPERATIONS || UNHOLD || Operation || Mandatory || SI==4 && ES > 2&& ES!=6 ||  ||
 +
|-
 +
| OPERATIONS || SUSPEND || Operation || Mandatory || SI==4 && ES > 2&& ES!=7 ||  ||
 +
|-
 +
| OPERATIONS || UNSUSPEND || Operation || Mandatory || SI==4 && ES > 2&& ES!=7 ||  ||
 +
|-
 +
| OPERATIONS || CONTI || Operation || Mandatory || SI==4 && OM==4 ||  ||
 +
|-
 +
| OPERATIONS || STARTUP || Operation || Mandatory || SI==4 && OM==4 ||  ||
 +
|-
 +
| OPERATIONS || SHUTDOWN || Operation || Mandatory || SI==4 && OM==4 ||  ||
 +
|-
 +
|  || STATUS || Property Group || Mandatory || SI==4 ||  ||
 +
|-
 +
| STATUS || ER || Property || Mandatory || SI==4 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Error_state_state_machine|Error States]]
 +
|-
 +
| STATUS || ERLAST || Property || Optional || SI==4 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Error_state_state_machine|Error States]]
 +
|-
 +
| STATUS || WORKST || Property || Mandatory || SI==4 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Work_state_state_machine|Work States]]
 +
|-
 +
| STATUS || OCCST || Property || Mandatory || SI==4 && OC > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Occupation_state_machine|Occupation States]]
 +
|-
 +
| STATUS || OCCUPIER || Property || Mandatory || SI==4 && OC > 1 || String || [occupier id]
 +
|-
 +
| STATUS || OCCLAST || Property || Optional || SI==4 && OC > 1 || String || [id of last occupier]
 +
|-
 +
| STATUS || EXMODE || Property || Mandatory || SI==4 && EM > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution_mode_state_machine|Execution Modes]]
 +
|-
 +
| STATUS || EXST || Property || Mandatory || SI==4 && ES > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution_state_state_machine|Execution States]]
 +
|-
 +
| STATUS || OPMODE || Property || Mandatory || SI==4 && OM > 1 || String || [[BaSyx_/_Documentation_/_API_/_ControlComponent#Operation_Mode_state_machine|Operation Modes]]
 +
|}
 +
<!-- TODO describe advantages -->
 +
<!-- TODO Describe other facets in detail:
 
==== SI Facet SERVICES ====
 
==== SI Facet SERVICES ====
 +
 +
==== SI Facet VARIABLES ====
 
-->
 
-->
 
<!-- TODO Show example pictures of opcua (from profile_server example)-->
 
<!-- TODO Show example pictures of opcua (from profile_server example)-->
Line 175: Line 455:
  
 
The execution mode facet category describes which execution modes are available.
 
The execution mode facet category describes which execution modes are available.
A component is assumed to be in AUTO like mode at all time, if the ES value is NONE.
+
A component is assumed to be in AUTO like mode at all time, if the EM value is NONE.
An ES value of two or higher (ANY) requires a EXMODE variable to determine the current mode.
+
An EM value of two or higher (ANY) requires a EXMODE variable to determine the current mode.
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 185: Line 465:
 
| 1|| 1|| NONE    || Always in AUTO || -
 
| 1|| 1|| NONE    || Always in AUTO || -
 
|-
 
|-
| 2|| 2|| MANUAL  || Additional manual mode available || AUTO, MANUAL
+
| 2|| 2|| AUTO    || Additional AUTO mode available || AUTO
 
|-
 
|-
| 3|| 4|| SEMIAUTO || Additional semiautomatic mode available || AUTO, SEMIAUTO
+
| 3|| 4|| MANUAL  || Additional manual mode available || MANUAL
 
|-
 
|-
| 4|| 8|| SIMULATE || Additional simulation mode available  || AUTO, SIMULATE
+
| 4|| 8|| SEMIAUTO || Additional semiautomatic mode available || SEMIAUTO
 +
|-
 +
| 5|| 16|| SIMULATE || Additional simulation mode available  || SIMULATE
 
|-
 
|-
 
|}
 
|}
<!-- DISCUSS
 
    AUTO mode always available, like FREE in OC profile.
 
-->
 
  
 
=== ES Facets ===
 
=== ES Facets ===
Line 207: Line 486:
  
 
{| class="wikitable"
 
{| class="wikitable"
! Bit !! Value !! Name !! Description !! Reference
+
! Value !! Name !! Description !! Reference
 +
|-
 +
| 0|| UNKNOWN || See [[#Facet Category Values|category values]] || -
 +
|-
 +
| 1|| NONE    || Always in EXECUTE state || Minimal state model<ref name="D-PC2.3"/>
 +
|-
 +
| 2|| BASYS  || Subset of PackML (Start, Stop, Reset, Abort) || Minimal PackML state machine<ref name="D-PC2.3"/><!--Abbildung 8--><!-- BaSys IPSMS specification -->
 +
|-
 +
| 3|| PACKML  || PackML state machine || ISA TR88.00.02-2008<ref name="PackML"/>
 +
|-
 +
| 4|| ISA88  || ISA88 procedural elements state machine || ANSI/ISA-88.00.01-2010<ref name="ISA88">ISA-S88 Part 1 – Batch Control Models and Terminology (IEC 61512-1)</ref>
 +
|-
 +
| 5|| MTP    || MTP state machine || MTP Part 4<ref name="MTP">VDI/VDE/NAMUR 2658 Part 4 - Modelling of module services</ref>
 +
|-
 +
| 6|| OPCUA  || OPC UA program state machine || OPC UA Part 10<ref name="OPCUA-Part10">IEC 62541 Part 10 – Programs</ref>
 +
|-
 +
| 7|| NE160  || NE160 procedure state machine  || NAMUR NE160<ref name="NE160">NAMUR NE160 - Ein Referenzmodell für allgemeine Prozedurbeschreibungen, NAMUR, 2016.</ref>
 +
|-
 +
|}
 +
 
 +
Even though the state machines differ in their number of states, their names can be mapped to each other, as shown in the following table.
 +
The MTP column also shows corresponing bit numbers.
 +
{| class="wikitable"
 +
! Order !! BASYS !! PACKML !! ISA88 !! MTP !! OPCUA !! NE160
 +
|-
 +
! START
 +
| START || Start || START || Start(2) || Start || START
 
|-
 
|-
| -|| 0|| UNKNOWN || See [[#Facet Category Values|category values]] || -
+
! STOP
 +
| STOP || Stop || STOP || Stop(3) || Halt ||  
 
|-
 
|-
| 1|| 1|| NONE    || Always in EXECUTE state || Minimal state model<ref name="D-PC2.3"/>
+
! RESET
 +
| RESET || Reset || RESET || Reset(1) || Reset ||  
 
|-
 
|-
| 2|| 2|| BASYS  || Subset of PackML (Start, Stop, Reset, Abort) || Minimal PackML state machine<ref name="D-PC2.3"/><!--Abbildung 8--><!-- BaSys IPSMS specification -->
+
! ABORT
 +
| ABORT || Abort || ABORT || Abort(8) || || ABORT
 
|-
 
|-
| 3|| 4|| PACKML  || PackML state machine || ISA TR88.00.02-2008<ref name="PackML"/>
+
! CLEAR
 +
| CLEAR || Clear || RESET || (Reset(1)) ||  || RESET
 
|-
 
|-
| 4|8|| ISA88  || ISA88 procedural elements state machine || ANSI/ISA-88.00.01-2010<ref name="ISA88">ISA-S88 Part 1 – Batch Control Models and Terminology (IEC 61512-1)</ref>
+
! HOLD
 +
|  || Hold || HOLD || Hold(4) ||  || LOCK
 
|-
 
|-
| 5|| 16|| MTP    || MTP state machine || MTP Part 4<ref name="MTP">VDI/VDE/NAMUR 2658 Part 4 - Modelling of module services</ref>
+
! UNHOLD
 +
| || Unhold || RESTART || Unhold(5) || || UNLOCK
 
|-
 
|-
| 6|| 32|| OPCUA  || OPC UA program state machine || OPC UA Part 10<ref name="OPCUA-Part10">IEC 62541 Part 10 – Programs</ref>
+
! SUSPEND
 +
| || Suspend || PAUSE || Pause(6)|| Suspend ||  
 
|-
 
|-
| 7|| 64|| NE160  || NE160 procedure state machine  || NAMUR NE160<ref name="NE160">NAMUR NE160 - Ein Referenzmodell für allgemeine Prozedurbeschreibungen, NAMUR, 2016.</ref>
+
! UNSUSPEND
 +
| || Unsuspend || RESUME || Resume(7)|| Resume ||  
 
|-
 
|-
 +
! Not Assigned
 +
|  ||  ||  || Restart(9) ||  || RESTART
 
|}
 
|}
  
Line 231: Line 546:
 
The operation mode facets define whether different operation modes are selectable.
 
The operation mode facets define whether different operation modes are selectable.
 
A control component with an OM value of two or higher has to represent the current operation mode via OPMODE state variable.
 
A control component with an OM value of two or higher has to represent the current operation mode via OPMODE state variable.
The OM value NONE yields to a control component, that has no operation modes to select and is therefore assumed to be in BSTATE (basic state) at all time.  
+
The OM value NONE yields to a control component, that has no operation modes to select and is therefore assumed to be in basic state (BSTATE) at all time.
  
 
{| class="wikitable"
 
{| class="wikitable"
! Bit !! Value !! Name !! Description
+
! Value !! Name !! Description
 
|-
 
|-
| -|| 0|| UNKNOWN  || See [[#Facet Category Values|category values]]
+
| 0|| UNKNOWN  || See [[#Facet Category Values|category values]]
 
|-
 
|-
| 1|| 1|| NONE    || Only one operat mode (BSTATE).
+
| 1|| NONE    || No operation mode selection possible.
 
|-
 
|-
| 2|| 2|| MULTI    || Multiple, application specific modes available.
+
| 2|| MULTI    || One or multiple, application specific modes, that need to be selected.
 
|-
 
|-
| 3|| 4|| PARALLEL || Parallel executable operation modes with own execution states. See [[BaSyx_/_Documentation_/_API_/_ControlComponent#Components with concurrent behavior|components with concurrent behavior]].
+
| 3|| PARALLEL || Parallel executable operation modes with own execution states. See [[BaSyx_/_Documentation_/_API_/_ControlComponent#Components with concurrent behavior|components with concurrent behavior]].
 
|-
 
|-
| 4|| 8|| CONTI    || Conti process operation mode with startup and shutdown: BSTATE, STARTUP, SHUTDOWN
+
| 4|| CONTI    || Conti process operation mode with startup and shutdown: CONTI, STARTUP, SHUTDOWN
 
|-
 
|-
 
|}
 
|}

Latest revision as of 11:25, 2 December 2020

Warning2.png
This information is work in progress as part of the BaSys 4.2 project. This section is preliminary and subject to change during the project.


Overview | Interface | Implementation

Profiles

An example control component in OPC UA realizing different facets.

A profile is a composition of facets from different facet categories. For example a control component profile can be defined by the following facets.

  • SI = 4 (OPERATIONS)
  • OC = 6 (OCCUPIED,PRIO)
  • EM = 2 (MANUAL)
  • ES = 4 (PACKML)
  • OM = 2 (MULTI)

The address space of a control component in OPC UA conforming to this profile is shown in the figure.

Facets ordered in different facet categories may describe a huge variety of control component realizations. Consequently, profiles are needed to reduce the amount of facet combinations to a usefull subset. Examples of control component dummies in OPC UA can be found in the [ccProfilesUA project].

Profile Definition

Every profile will refer to at least one facet from every facet category and will therefore be considered as full featured profile. Hence, applications can be developed and implemented against single facet values or whole profiles. The following profiles are currently defined and may be extended in the future:

  • MINIMAL 
    Minimal requirements for the component and service interface. May be used for the integration of sensors.
  • BASYS 
    Default profile for control components conform to the BaSys 4.2 project. Used in BaSys demonstrators.
  • FULL 
    Maximum features of the control component with all interfaces available.
  • PACKML 
    Control components that are fully compatible to PackML.
  • MTP 
    Control components that are described and conform to NAMUR Module-Type-Package (MTP).

The following table defines the described profiles by referencing according facet values. As different standards like PackML allow for variations themselves (e.g. availability of SEMIAUTO execution mode), only minimal requirements are set.

Profile Service Interface (SI) Occupation (OC) Execution Modes (EM) Execution States (ES) Operation Modes (OM)
MINIMAL 1 1 1 1 1
BASYS 4 6 6 2 2
FULL 62 14 30 3 3
PACKML 32 1 6 3 1
MTP 16 1 6 5 3

BASYS Default Profile

The default profile for BaSys control components has an OPERATIONS service interface, conform to VAB Implementation. It has a simple occupation state machine with one priorytized state (OCCUPIED, PRIO) and no local overwrite. Moreover, at least the MANUAL and AUTO execution mode must be available. As execution state machine a subset of PackML and ISA88 exuction states are selected. Multiple operation modes may be available, but only one operation mode is active at a time and needs to be selected beforehand.

Profile Interface Specification

In order to describe the variant and its features, respectively the profile, of a control component an interface specification is given here. It may be used in type or instance descriptions, e.g. in AAS submodels, or even in the control component itself. A self description of control components is an important feature to enable plug and produce scenarios.

Parent Name Type Rule Property Datatype Property Values
PROFILE Property Group Optional
PROFILE SI Property Optional String SI Facets
PROFILE OC Property Optional String OC Facets
PROFILE EM Property Optional String EM Facets
PROFILE ES Property Optional String ES Facets
PROFILE OM Property Optional String OM Facets

Profile Compliance Testing

Compliance tests need to be defined in order to verify that a control component conforms to a profile or specific facets. These tests can be static, checking the interface according to the interface specifications in the SI Facets. Moreover, behavioural tests can be defined based on the standardized state machines. These test may be even be used to explore the profile of an unknown control component, which could be used in a plug and produce procedure for example.

An implementation and description for test cases and example dummies in OPC UA utilizing the Google-Test framework can be found [ccProfilesUA project].

Facet Categories

BaSys control components may be described by the following facet categorys:

SI - Service Interface Facet Category
Describes how the offered services are structured and how states are represented.
This facet category is special, because it is orthogonal to the other facet categories. Hence, a control component interface looks a bit different, if different facets from the other facet categories are realised.
OC - Occupation Facet Category
Describes whether a occuption is necessary.
Variants may describe whether a occupation with priority or local is possible.
EM - Execution Modes Facet Category
Describes whether different execution modes are possible.
Variants may describe which modes are possible and how they are called.
ES - Execution States Facet Category
References the used execution states and their transitions.
May describe variants or subsets of a full execution state state machines.
OM - Operation Modes Facet Category
Describes whether multiple operation modes are available and need to be selcted.
Variants may describe whether there are specific operation modes, like fallback or startup and shutdown modes.

Facet Category Values

All facets have a name and are identfied with an positiv integer or zero. In order to combine facet category values and to use them as statements some common values are equal for all profiles, which is presented in the following table. If a facet category value is higher than one, ANY facet is defined for a facet category, which is opositional to the NONE value.

Facet categories may either describe a group of features that are combinable or a variant point that lists alternative realizations. If different facets in one facet group may be combined they are defined by bitmasks. Hence their values are multiples of two and combinations may be represented by bit order operations and integer values. Otherwise enumerations with an increment of one are used for alternative facet categories.

Bit Value Name Description
1 0 UNKNOWN No statement about profile or not determined
1 1 NONE Facet category is not realised, used, compliant or implemented
2..n >1 ANY One ore more facet category values, but not specified which ones
2 2 ... First specific facet of the facet category.
n 2^n ... Nth specific facet of the facet category.

Facets

The following table shows an overview of all facet values. The left (blue) part are combineable values realized as bitmasks, the right (green) part are alternative single values.

Bit / Value Service Interface (SI) Occupation (OC) Execution Modes (EM) Value Execution States (ES) Operation Modes (OM)
0 / 0 UNKNOW 0 UNKNOWN
1 / 1 NONE 1 NONE
2 / 2 CMD OCCUPIED AUTO 2 BASYS MULTI
3 / 4 OPERATIONS PRIO MANUAL 3 PACKML PARALLEL
4 / 8 SERVICES LOCAL SEMIAUTO 4 ISA88 CONTI
5 / 16 MTP SIMULATE 5 MTP
6 / 32 PACKML 6 OPCUA
7 / 64 7 NE160


SI Facets

The control component service interface E1 may be realised in various ways. Basys classifies different realisations via facets from the SI facet category. The service interface category (SI) describes how a control component can be affected by the means of orchestration and how the resulting state changes may be observed. Therefore each facet defines how the activation interaction likewise the writing of variables or invocation of operations is handled. Moreover, a component has aggregated state values for its state machines, which may be represented by one or more variables at different adresses. State change events may be raised if state variable values change. Consequently, the SI facets also define how to find the addresses or endpoints of its activation and reaction represenations.

The following table presents an overview and small comparision of possible SI facets. The major facet for the service interface used in basys is OPERATIONS.

Bit SI value Name Activation mechanism Aggregated state represenation Utiliziation recommendation
1 0 - 1 UNKNOWN, NONE Not defined Not defined See category values
2 2 CMD A string variable called CMD (command input) with a specific syntax is used to activate service operations A flat list of variables of all aggregated component states under a containing element (folder) Process control applications with IEC 61131[1]
3 4 OPERATIONS A flat list of operations of all offered services under a containing element (folder) A flat list of variables of all aggregated component states under a containing element (folder) Advanced components or as additional interface
4 8 SERVICES Operations are grouped under service elements State variables are grouped under service elements Advanced and modular components
5 16 VARIABLES Multiple (spread) variables are used to activate service operations Multiple (spread) variables are used to represent the component states Very generic but needs mapping description. Not standardized browseable. May be mapped to NAMUR MTP

Note on NAMUR Module Type Package (MTP): in the future, basys will map the description for the orchestration of modules that are described via a NAMUR MTP to facets or even to a profile. Therefore an existing facets like VARIABLES may be used or a new facet may be necessary.

SI Facet CMD

An example control component in OPC UA realizing the CMD service interface.

The SI facet CMD determins a control component with a command interface, based on [2]. The command interface consists of at least one string variable called the command input or CMD, that uses the following syntax:

<Sender>;<Order>;[<Parameter1=Value1>,<Parameter2=Value2>,<...>]

Interface specification for facet CMD (All specifications: File:BaSyx-ControlComponentProfiles-Interface Specification-xls.zip):

Parent Name Type Rule Facets Property Datatype Property Values Property Writeable
CMD Property Mandatory SI==2 String [sender];[order];[param1=value1,...] Writeable
CMDLAST Property Optional SI==2 String [last accepted command]
CMDOLIST Property Optional SI==2 String[] [list of supported orders]
CMDOPREF Property Optional SI==2 String[] [list of required parameters for each order]
STATUS Property Group Mandatory SI==2
STATUS ER Property Mandatory SI==2 String Error States
STATUS ERLAST Property Optional SI==2 String Error States
STATUS WORKST Property Mandatory SI==2 String Work States
STATUS OCCST Property Mandatory SI==2 && OC > 1 String Occupation States
STATUS OCCUPIER Property Mandatory SI==2 && OC > 1 String [occupier id]
STATUS OCCLAST Property Optional SI==2 && OC > 1 String [id of last occupier]
STATUS EXMODE Property Mandatory SI==2 && EM > 1 String Execution Modes
STATUS EXST Property Mandatory SI==2 && ES > 1 String Execution States
STATUS OPMODE Property Mandatory SI==2 && OM > 1 String Operation Modes

Some major advantages of this facet are:

  • The CMD variable is a single endpoint for orders. So an (atomic) write operation is sufficient to for every order including parameter setting.
  • The CMD input is easy to use and implement in different technologies, as only the transfer of a string is necessary.
    • The control component can process the command asynchrounus in its own cycletime.
    • No operations are needed. Some technologies or embedded devices (especially PLCs) do not provide invokation or remote procedure call functionality.
  • The control component does an implicit type conversion for parameters, so no user side browsing for exact types and casting is necessary.
  • Parameters may even be written separately, before sending an command, if they are realised as own variables. This is usefull for default parameters or if different sources are responsible for different parameters.
  • A batch of commandos is easily human readable.

SI Facet OPERATIONS

An example control component in OPC UA realizing the OPERATIONS service interface.

The SI facet OPERATIONS determines a control component service interface with a flat list of operations. Operation names are equal to the order names in the command input. Hence, a operation call corresponds to a command request.

Interface specification for facet OPERATIONS (All specifications: File:BaSyx-ControlComponentProfiles-Interface Specification-xls.zip):

Parent Name Type Rule Facets Property Datatype Property Values
OPERATIONS Property Mandatory SI==4 Map
OPERATIONS FREE Operation Mandatory SI==4 && OC&(2|4)
OPERATIONS OCCUPY Operation Mandatory SI==4 && OC&2
OPERATIONS PRIO Operation Mandatory SI==4 && OC&4
OPERATIONS AUTO Operation Mandatory SI==4 && EM > 1
OPERATIONS MANUAL Operation Mandatory SI==4 && EM&2
OPERATIONS SEMIAUTO Operation Mandatory SI==4 && EM&4
OPERATIONS SIMULATE Operation Mandatory SI==4 && EM&8
OPERATIONS START Operation Mandatory SI==4 && ES > 1
OPERATIONS STOP Operation Mandatory SI==4 && ES > 1&& ES!=7
OPERATIONS RESET Operation Mandatory SI==4 && ES > 1&& ES!=7
OPERATIONS ABORT Operation Mandatory SI==4 && ES > 1&& ES!=6
OPERATIONS CLEAR Operation Mandatory SI==4 && ES > 1&& ES!=6
OPERATIONS HOLD Operation Mandatory SI==4 && ES > 2&& ES!=6
OPERATIONS UNHOLD Operation Mandatory SI==4 && ES > 2&& ES!=6
OPERATIONS SUSPEND Operation Mandatory SI==4 && ES > 2&& ES!=7
OPERATIONS UNSUSPEND Operation Mandatory SI==4 && ES > 2&& ES!=7
OPERATIONS CONTI Operation Mandatory SI==4 && OM==4
OPERATIONS STARTUP Operation Mandatory SI==4 && OM==4
OPERATIONS SHUTDOWN Operation Mandatory SI==4 && OM==4
STATUS Property Group Mandatory SI==4
STATUS ER Property Mandatory SI==4 String Error States
STATUS ERLAST Property Optional SI==4 String Error States
STATUS WORKST Property Mandatory SI==4 String Work States
STATUS OCCST Property Mandatory SI==4 && OC > 1 String Occupation States
STATUS OCCUPIER Property Mandatory SI==4 && OC > 1 String [occupier id]
STATUS OCCLAST Property Optional SI==4 && OC > 1 String [id of last occupier]
STATUS EXMODE Property Mandatory SI==4 && EM > 1 String Execution Modes
STATUS EXST Property Mandatory SI==4 && ES > 1 String Execution States
STATUS OPMODE Property Mandatory SI==4 && OM > 1 String Operation Modes

OC Facets

The occupation facet category describes, whether a control component can be occupied. This is important for an orchestrator, as it has to be checked, whether the component is free and it has to be occupied before operation. Further more, the occupation facets determine, whether it is possible to occupy the component with a higher priority, for example by an operator or maintenance person. An OC value of two or higher (ANY) requries the component to have an OCCUPIER variable to determine who occupies the component. Moreover, the OCCST variable is needed to differentiate occupation states.

Bit Value Name Description Possible OCCST values Possible ORDERs
- 0 UNKNOWN See category values Undefined Undefined
1 1 NONE No occupation necessary - -
2 2 OCCUPIED Normal occupation possible FREE, OCCUPIED FREE, OCCUPY
3 4 PRIO Priority occupation possible FREE, PRIO FREE, PRIO
4 8 LOCAL Local overwrite FREE, LOCAL

EM Facets

The execution mode facet category describes which execution modes are available. A component is assumed to be in AUTO like mode at all time, if the EM value is NONE. An EM value of two or higher (ANY) requires a EXMODE variable to determine the current mode.

Bit Value Name Description Possible EXMODE values = Possible ORDERs
- 0 UNKNOWN See category values Undefined
1 1 NONE Always in AUTO -
2 2 AUTO Additional AUTO mode available AUTO
3 4 MANUAL Additional manual mode available MANUAL
4 8 SEMIAUTO Additional semiautomatic mode available SEMIAUTO
5 16 SIMULATE Additional simulation mode available SIMULATE

ES Facets

In general different execution state machines or subsets are used in different domains or companies. BaSys recommends the use of the PackML [3] state machine, as it is possible to map at least state and order names of other state machines to it. At the moment only the facets 0 to 4 are supported in basys and are therefore used in the full featured profiles. [4]

The EXST variable has to be present, if an ES value of two (ANY) or higher is given. A control component with ES value one (NONE) is assumed to be in the EXECUTE state at all time and hence it can not be halted, suspended, stopped or aborted.

Value Name Description Reference
0 UNKNOWN See category values -
1 NONE Always in EXECUTE state Minimal state model[4]
2 BASYS Subset of PackML (Start, Stop, Reset, Abort) Minimal PackML state machine[4]
3 PACKML PackML state machine ISA TR88.00.02-2008[3]
4 ISA88 ISA88 procedural elements state machine ANSI/ISA-88.00.01-2010[5]
5 MTP MTP state machine MTP Part 4[6]
6 OPCUA OPC UA program state machine OPC UA Part 10[7]
7 NE160 NE160 procedure state machine NAMUR NE160[8]

Even though the state machines differ in their number of states, their names can be mapped to each other, as shown in the following table. The MTP column also shows corresponing bit numbers.

Order BASYS PACKML ISA88 MTP OPCUA NE160
START START Start START Start(2) Start START
STOP STOP Stop STOP Stop(3) Halt
RESET RESET Reset RESET Reset(1) Reset
ABORT ABORT Abort ABORT Abort(8) ABORT
CLEAR CLEAR Clear RESET (Reset(1)) RESET
HOLD Hold HOLD Hold(4) LOCK
UNHOLD Unhold RESTART Unhold(5) UNLOCK
SUSPEND Suspend PAUSE Pause(6) Suspend
UNSUSPEND Unsuspend RESUME Resume(7) Resume
Not Assigned Restart(9) RESTART

OM Facets

The operation mode facets define whether different operation modes are selectable. A control component with an OM value of two or higher has to represent the current operation mode via OPMODE state variable. The OM value NONE yields to a control component, that has no operation modes to select and is therefore assumed to be in basic state (BSTATE) at all time.

Value Name Description
0 UNKNOWN See category values
1 NONE No operation mode selection possible.
2 MULTI One or multiple, application specific modes, that need to be selected.
3 PARALLEL Parallel executable operation modes with own execution states. See components with concurrent behavior.
4 CONTI Conti process operation mode with startup and shutdown: CONTI, STARTUP, SHUTDOWN

References

  1. Grothoff, J et al (2019) Komponentenbasierte Automatisierung: Realisierung einer flexiblen Schnittstelle zur Auftragsorientierten Prozessführung in IEC 61131-3 Umgebungen, AUTOMATION 20219, Baden-Baden
  2. Wagner, C. & Epple, U. (2015) Sprechende Kommandos als Grundlage moderner Prozessführungsschnittstellen, AUTOMATION 2015, Baden-Baden
  3. 3.0 3.1 ISA-TR88.00.02-2008 Machine and Unit States: An Implementation Example of ISA-88.
  4. 4.0 4.1 4.2 Wagner, C., Grothoff, J., Epple, U., Grüner, S., Wenger, M., & Zoitl, A. (2018). Ein Beitrag zu einem einheitlichen Engineering für Laufzeitumgebungen, 19. Leitkongress der Mess- und Automatisierungs-technik, Baden-Baden.
  5. ISA-S88 Part 1 – Batch Control Models and Terminology (IEC 61512-1)
  6. VDI/VDE/NAMUR 2658 Part 4 - Modelling of module services
  7. IEC 62541 Part 10 – Programs
  8. NAMUR NE160 - Ein Referenzmodell für allgemeine Prozedurbeschreibungen, NAMUR, 2016.
BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation

Back to the top