Skip to main content
Jump to: navigation, search

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

m (Control component profiles: Fixed EM profile description row in table. Fixed some links.)
(Removed profile sections. (Moved to own page))
Line 467: Line 467:
  
 
BaSys 4.0 components should report exactly one error state for every occurring fault. BaSys does not define a generic fault automaton that describes the error state of a component. If a control component is in normal operation, it should communicate error state 0 (OK).  
 
BaSys 4.0 components should report exactly one error state for every occurring fault. BaSys does not define a generic fault automaton that describes the error state of a component. If a control component is in normal operation, it should communicate error state 0 (OK).  
 
=== Control component profiles ===
 
<!-- BaSys 4.2 Deliverable D-4.6 -->
 
{{warning|1=
 
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.
 
}}
 
 
The abstract concept of [[BaSyx_Control_Components|control components]] and their [[#Control component state machines|state machines]] may be realised in technology specific ways or focussed on certain aspects.
 
For example an [[#Occupation state machine|occupation]] might not be necessary or a smaller [[#Execution state state machine|execution state machine]] may be satisfying.
 
Especially domain, task or company specific constraints may need to be applied in brownfield scenarios.
 
In order to describe basys control components in a standardized manner and to ensure the compliance of basys labled control components, possible realisation types are clustered in profiles.
 
The Profiles may be used for the typification und type description of control components.
 
Furthermore, they can be used to define requirements of a component system or its orchestration environment.
 
 
One goal of ''BaSys 4.2'' is to enable plug and produce scenarios via standardized procedures.
 
Considering that, the requirements of heterogenous industrial production systems and the offered features of various control components need be described and matched.
 
In order to support this matching in an automated manner a limitation and standardization to usefull profiles is necessary.
 
Combinations of commonly used profiles will be used to define integration variants for easier commponent development and usage.
 
Finally adapters may be generated to integrate components of different profiles.
 
 
In conclusion [[#Control component profiles|control component profiles]] describe which design patterns are used for a control component or its type in a standardized manner.
 
Hence they are linked to the basys design patterns which rely on the [[#Control component state machines|control comopnent state machines]].
 
The goal is to reference existing standards and to build a bridge between component creators and their users.
 
In the context of I4.0 it is recommended to use the control component submodel in the asset administrator shell (AAS) to describe required or assured profiles of a control component.
 
<!-- TODO Create and link wiki article for control component submodel -->
 
 
[[File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|thumb|An example control component in OPC UA with the following profile: SI=5, OC=4, EM=3, ES=3, OM=4]]
 
BaSys control components may be described by the following profiles:
 
;SI - [[#Service interface profile|Service Interface Profile]]
 
: Describes how the offered [[#Control component interface|services]] are structured and how states are represented.
 
: This profile is special, because it is orthogonal to the other profiles. Hence, every other profile looks a bit different, if a different SI profile is realised in component.
 
;OC - [[#OC profile|Occupation Profile]]
 
: Describes whether a [[#Occupation state machine|occuption]] is necessary.
 
: Variants may describe whether a occupation with priority or local is possible.
 
;EM - [[#EM profile|Execution Modes Profile]]
 
: Describes whether different [[#Execution mode state machine|execution modes]] are possible.
 
: Variants may describe which modes are possible and how they are called.
 
;ES - [[#ES profile|Execution States Profile]]
 
: References the used [[#Execution state state machine|execution states]] and their transitions.
 
: May describe variants or subsets of a full execution state state machines.
 
;OM - [[#OM profile|Operation Modes Profile]]
 
: Describes whether multiple [[#Operation mode state machine|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.
 
Note: more profiles may be added in the future.
 
 
For example a control component could have the following profile values.
 
* SI = 5 (OPERATIONS)
 
* OC = 4 (PRIO)
 
* EM = 3 (MANUAL)
 
* ES = 3 (PACKML)
 
* OM = 4 (MULTI)
 
The address space of a control component interface in OPC UA is shown in the [[:File:BaSyx-ControlComponent-Example-OPCUA-SI5-OC4-EM3-ES3-OM4.png|figure]].
 
<!-- TODO add more examples -->
 
<!-- TODO maybe move examples to "Implementation" page? -->
 
 
==== Common profile values ====
 
 
All profiles shall be determined with an positiv integer or zero, respectively enums may be implemented.
 
In order to combine profile values and to use them as statements some common values are equal for all profiles, which is presented in the following table.
 
{| class="wikitable"
 
! Value !! Name !! Description
 
|-
 
| 0 || UNKNOWN  || No statement about profile or not determined
 
|-
 
| 1 || NONE    || Profile is not realised, used, compliant or implemented
 
|-
 
| 2 || ANY      || One ore more profile values, but not specified which ones
 
|-
 
| 3 - n || Profile specific || Specific variants of the profile.
 
|-
 
|}
 
<!-- TODO define a way how profile values can be concenated, as bitmask for example. -->
 
 
<!-- DISCUSS
 
    - whether the profiles section should be moved to an own page
 
    - whether the specific profile sections should be moved to the corresponding state machines
 
-->
 
 
==== OC profile ====
 
 
The occupation profile 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 profile determins, whether it is possible to occupy the component with a higher priority, for example by an operator or maintenance person.
 
An OC profile value of two (ANY) or higher requries the component to have an OCCUPIER variable to determine who occupies the component.
 
If the OC profile value is four (PRIO) or higher, the OCCST variable is needed to d occupation states.
 
 
{| class="wikitable"
 
! Value !! Name !! Description !! Possible OCCST values
 
|-
 
| 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values]] || Undefined
 
|-
 
| 3 || OCCUPIED || Only one occupier || OCCUPIED
 
|-
 
| 4 || PRIO    || Priority possible || OCCUPIED, PRIO
 
|-
 
| 5 || LOCAL    || Local overwrite  || OCCUPIED, PRIO, LOCAL
 
|-
 
|}
 
 
==== EM profile ====
 
 
The execution mode profile 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.
 
An ES value of three (MANUAL) or higher demands a EXMODE variable to determine the mode.
 
 
{| class="wikitable"
 
! Value !! Name !! Description !! Possible EXMODE values
 
|-
 
| 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values]] || Undefined
 
|-
 
| 3 || MANUAL  || Additional manual mode available || AUTO, MANUAL
 
|-
 
| 4 || SEMIAUTO || Additional semiautomatic mode available || AUTO, SEMIAUTO, MANUAL
 
|-
 
| 5 || SIMULATE || Additional simulation mode available  || AUTO, SEMIAUTO, MANUAL, SIMULATE
 
|-
 
|}
 
 
<!-- DISCUSS
 
    add more combinations with SIMULATE mode: SIMAUTO (AUTO + SIM), SIMMANU (AUTO + MANUAL + SIM) and SIMSEMI ... ?
 
-->
 
 
==== ES profile ====
 
 
The execution state profile defines which execution state machine is used by a reference to common standards.
 
BaSys recommends the use of the PACKML profile as it is possible to map the other state machines to it.
 
<ref name="D-PC2.3">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.</ref>
 
The EXST variable has to be present, if an ES value of two (ANY) or higher is given.
 
A control component with ES profile 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.
 
 
{| class="wikitable"
 
! Value !! Name !! Description !! Reference
 
|-
 
| 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values]] || Undefined
 
|-
 
| 3 || PACKML  || PackML state machine        || ISA TR88.00.02-2008<ref name="PackML">ISA-TR88.00.02-2008 Machine and Unit States:  An Implementation Example of ISA-88.</ref>
 
|-
 
| 4 || ISA88    || ISA88 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 || BASYS    || Subset of PackML (Start, Stop, Reset) || PackML without held, suspended, aborted and corresponding active states.<!-- BaSys IPSMS specification -->
 
|-
 
|}
 
 
==== OM profile ====
 
 
The operation mode profile defines 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 BSTATE (basic state) at all time.
 
 
{| class="wikitable"
 
! Value !! Name !! Description
 
|-
 
| 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values]]
 
|-
 
| 3 || CONTI    || Conti process operation mode with startup and shutdown: BSTATE, STARTUP, SHUTDOWN
 
|-
 
| 4 || MULTI    || Multiple, application specific modes available.
 
|-
 
| 5 || PARALLEL || Parallel executable operation modes with own execution states. See [[#Components with concurrent behavior|components with concurrent behavior]].
 
|}
 
 
<!-- TODO Reference profile_example and test_compliance tool from RWTH
 
==== Profile Compliance Testing ====
 
-->
 
  
 
=== Components with concurrent behavior ===
 
=== Components with concurrent behavior ===
Line 641: Line 473:
 
* Development of one control component that applies internal mappings to map concurrent device behavior to control component state machines
 
* Development of one control component that applies internal mappings to map concurrent device behavior to control component state machines
 
* Development of multiple control components that control independent aspects of the controlled device.
 
* Development of multiple control components that control independent aspects of the controlled device.
 
 
  
 
=== Control component interface ===
 
=== Control component interface ===
Line 664: Line 494:
 
* E5: Native device interface
 
* E5: Native device interface
 
** Device components use the native device interface to interact with native devices. This communication endpoint implements any proprietary communication that is necessary to control a device, and to access its properties and services.
 
** Device components use the native device interface to interact with native devices. This communication endpoint implements any proprietary communication that is necessary to control a device, and to access its properties and services.
 
==== Service interface profile ====
 
<!-- BaSys 4.2 Deliverable D-3.2 -->
 
{{warning|1=
 
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.
 
}}
 
 
The [[#Control component interface|control component service interface]] '''E1''' may be realised in various ways.
 
Basys classifies different realisations via [[#Control component profiles|profiles]].
 
The service interface profile ('''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 profile value 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 [[#Control component state machines|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 profile also defines 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 profile values.
 
The major profile of the service interface used in basys is ''OPERATIONS''.
 
 
{| class="wikitable"
 
! style="text-align:left;"| SI value
 
! Name
 
! Usage in Basys
 
! Activation mechanism
 
! Aggregated state represenation
 
! Utiliziation recommendation
 
|-
 
| 0 - 2
 
| UNKNOWN, NONE, ANY
 
| See [[#Common profile values|common profile values]]
 
| Not defined
 
| Not defined
 
| Probably not a compliant basys control component
 
|-
 
| 3
 
| VARIABLES
 
| Not used in basys
 
| 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
 
|-
 
| 4
 
| CMD
 
| Used in SMS Demonstrator (RWTH)
 
| 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
 
|-
 
| 5
 
| OPERATIONS
 
| Used in SMS and common Demonstrator (~All partners)
 
| 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
 
|-
 
| 6
 
| SERVICES
 
| Not used, upcomming in BaSys 4.2
 
| Operations are grouped under service elements
 
| State variables are grouped under service elements
 
| Advanced and modular components
 
|}
 
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 profiles.
 
Therefore an existing profile value like VARIABLES may be used or a new profile value may be necessary.
 
 
<!-- TODO Describe (important) profiles values in detail:
 
===== SI profile CMD =====
 
 
===== SI profile OPERATIONS =====
 
 
===== SI profile SERVICES =====
 
-->
 
<!-- TODO Show example pictures of opcua (from profile_server example)-->
 
  
 
== Virtual Automation Bus (VAB) implementation ==
 
== Virtual Automation Bus (VAB) implementation ==
Line 1,013: Line 771:
  
 
Additional gateways may implement additional mapping schemes, and may include control components and devices with non-conforming interfaces by implementing component and device specific mappings that provide a conforming façade to the VAB.
 
Additional gateways may implement additional mapping schemes, and may include control components and devices with non-conforming interfaces by implementing component and device specific mappings that provide a conforming façade to the VAB.
 
== References ==
 
 
<references/>
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
| BaSyx project links:  [[BaSyx | Project BaSyx main wiki page]]  <nowiki>|</nowiki>  [[BaSyx.WhatIsBasyx | What is BaSyx?]]  <nowiki>|</nowiki>  [[BaSyx.Documentation | BaSyx Developer Documentation]]
 
| BaSyx project links:  [[BaSyx | Project BaSyx main wiki page]]  <nowiki>|</nowiki>  [[BaSyx.WhatIsBasyx | What is BaSyx?]]  <nowiki>|</nowiki>  [[BaSyx.Documentation | BaSyx Developer Documentation]]
 
|}
 
|}

Revision as of 04:40, 20 January 2020

Overview | Interface | Implementation

BaSyx device Interface

BaSys 4.0 control components provide a harmonized interface to device services, and shield native device communication from users. The same physical device may provide several device control components at different network communication endpoints to control independent device services. The BaSyx device interface defines a generic interface to all control components, i.e. device control components and group control components. It defines a minimum common set of primitives that enables the issuing of commands, setting of states, and querying of results. Device specific extensions may be added to reflect device specific services, modes of operation, and status information, as well as other primitives. This section first describes the technology independent device interface, its realization in context of the Virtual Automation Bus as End-to-End communication medium and concrete technology mappings.


Technology independent interface concept

The BaSyx device interface defines the necessary primitives and the interface semantics of a BaSys 4.0 control component. The interface to a control component consists of defined orders and signals. Orders invoke component operations, signals are attributes.


Control component state machines

Defined state machines represent the status of a BaSys 4.0 component. The following state machines are defined for every BaSys component:

  • Occupation: The occupation state machine defines the occupation state of the component. An occupation realizes an exclusive lock to the control component. It defines who is using a control component. Some orders may only be issued if the issuer occupies the control component, i.e. iff he possesses the lock of the control component.
  • Execution mode: The execution mode state machine defines execution mode of the control component. The execution mode defines how a control component reacts to commands. Execution modes are for example the automatic mode of operation, which is the common mode of operation, or semi-automatic mode for setup operation. A control component is at every time in only one execution mode.
  • Execution state: The execution state communicates the execution state of a control component by using a PackML state machine. The execution state indicates the state of a control component in a specific execution mode.
  • Operation mode: Component operation modes are used to separate different capabilities of a component. By selecting an operation mode, the user of a component defines what a component will be doing.
  • Work state: The work state of a component defines the current, operation mode specific, state of a control component.
  • Error state: The error state of a control component indicates if an error did happen, or if the component is in normal operation.


Variables describe the status of each state machine. The following table illustrates the variable used by the predefined state machines of control components. Every control component may define additional state machines and variables to communicate information that is more specific. Control of state changes is via orders or input signals.

State machine Property Variable
Occupation Current occupation state OCCST
ID of current occupier OCCUPIER
ID of previous occupier OCCLAST
Execution mode Active execution mode EXMODE
Execution state Active execution state EXST
Operation mode Active operation state OPMODE
Work state Actual work state WORKST
Error state Actual error state ER
Previous error state ERLAST


Occupation state machine

The occupation state machine defines who is using the control component. The output signal OCCST describes the occupation state of BaSys 4.0 components. It defines four different states:

Signal value Name Description
0 FREE The component is currently not occupied
1 OCCUPIED The component is occupied by a different entity, e.g. by a different BaSys control component. This is the normal occupation state with priority 1
2 PRIORITY A different component did occupy the component with priority. This is for example an operator that wants to control the device manually, e.g. for configuring it or for testing device functions. This priority occupation is possible also if the component is in state OCCUPIED. The new occupier needs to make sure that no invalid operations are performed
3 LOCAL The component is occupied by a local entity. This always overrides OCCUPIED and PRIORITY occupations. LOCAL occupation is only possible via a local entity, e.g. an operator using a control panel. Implementation of this state is optional


The signal OCCUPIER provides the identifier of the current occupier of a control component. The signal OCCLAST holds the name of the previous occupier in case of a PRIORITY occupation. If the current occupier is overridden by a local override, the OCCUPIER signal will output “LOCAL”.

Controlling the occupation state machine is via orders and input signals. The component occupation state machine accepts three orders:

Order Parameter Description
FREE - Free component occupation if sender is occupier
OCCUPY - Occupy component
PRIO - Occupy component with priority

Every order contains the sender ID of the requesting entity. In addition, the component occupation state machine processes the input signals LocalOverwrite and LocalOverwriteFree that control the LOCAL occupation mode. The following state machines define the semantics of control component occupation without and with local override support:


Execution mode state machine

The execution mode state machine defines the current execution mode of a control component. It defines how a control component reacts to commands. The current mode of operation is exposed through signal EXMODE. Every control component defines the following basic modes of operation and signal values:

Signal value Name ISA-TR88.00.02 “PackML” ISA-88.00.01-2010 “ISA-88” Description
1 AUTO Producing Automatic Automatic operation. This is the normal operation of a device.
2 SEMIAUTO Maintenance Semi-automatic Maintenance operation. This execution mode is used for setup of automatic operation.
3 MANUAL Manual Manual Manual operation mode that enables manual intervention with explicit confirmation of machine operation by operator.
4 Future reserve Reserved for future mode that enables manual operation without explicit confirmation by operator
5 SIMULATION

(under discussion)

Simulation mode that behaves like automatic mode but does not issue any orders to devices/actuators

The execution modes are defined as following:

  • The automatic mode is the most common mode of operation for a machine. In this mode, safety measures must guarantee that operators cannot enter the operation area of a machine. This may be achieved for example by automatic locking doors or by switching off the machine immediately when a door is opened.
  • The semi-automatic mode supports setting up of a machine for automatic mode. In semi-automatic mode, machine functions are restricted. For example may the operation speed be significantly reduced compared to automatic mode. Operators need to actively confirm operation, e.g. by pressing and holding a button to keep the device moving.
  • The manual mode enables manual intervention into the automatic mode. It may be used for example to work manually on a complex work piece. This mode of operation enables the operator to monitor and control manufacturing processes with opened doors. A requirement for this mode is a substitute for safety measures, e.g. a moveable panel with an active confirmation. An example is a confirmation button that stops machine operation as soon as it is no longer pressed. Movement speeds are restricted but not as much as in semi-automatic mode.
  • A future reserved mode could be an extended maintenance mode that is permitted in special cases. It removes the need for a permanent active confirmation from maintenance mode, which is necessary in case of longer operation cycles. This mode will require a tailored safety concept for the machine.
  • The simulation mode is currently under discussion. It enables the integration of the control component into a virtualized plant. In this mode, the control component does not issue any orders to the controlled physical device.


Changes in execution mode may be triggered externally or internally. External triggers is an order, internal triggers may be for example a signal from a key switch or a detected fault. Changing of execution mode may require safety measures. The following order are supported by every BaSys component:

Order Parameter Description
AUTO - Change to execution mode AUTO
SEMIAUTO - Change to execution mode SEMIAUTO
MANUAL - Change to execution mode MANUAL


Execution state state machine

Every execution mode has execution states that define the state of a control component. BaSys describes execution modes with ISA-88-2 (PackML). Every BaSys component is at every time in exactly one execution state of exactly one execution mode. All execution states must be mapped to the states of the PackML state machine. Additional parallel state machines may be defined to provide additional, control component specific information. Signal EXST provides the execution state of a control component. The figure below defines the PackML state machine with execution states and state changes of BaSys control components. State changes are triggered either by the control component itself (transition SC – State Complete), or by an order (all other transitions). State changes triggered by the control component itself happen when a state did complete. This is for example because of the completion of a running operation.


Basyx.PackML.png


The meaning of the PackML states are as following:

  • IDLE The control component is idle and waits for orders and/or signals
  • STARTING The selected operation (operation mode) is starting. This state is entered when the START order is received by the control component.
  • EXECUTE The selected operation is executing. This state is entered after the STARTING command completes.
  • COMPLETING Execution of the selected operation did complete manually. The selected operation is completing.
  • COMPLETE The execution of the selected operation did complete normally.
  • RESETTING The control component (and its connected device if necessary) is resetting to IDLE state. This state is entered after the RESET command is received by the control component.
  • SUSPENDING The control component is suspending the device. This state is entered after the SUSPEND order is received
  • SUSPENDED The device is suspended. In this state the device is operational but nor producing anything.
  • UNSUSPENDING The device is being unsuspended, moving back to normal operation. This state is entered after the UNSUSPEND command is received.
  • HOLDING The device is being prepared for HELD state. This state is entered when the HOLD order is received.
  • HELD The device is held, i.e. temporarily stopped.
  • UNHOLDING The device is being moved back to EXECUTE state.
  • ABORTING This state is entered at any time in response to the ABORT order, on the occurrence of a machine fault, or in response of an emergency stop. The abort logic will bring the device to a rapid, controlled safe state.
  • ABORTED The machine is in a safe state. It retains information about the condition that die lead to abort state.
  • CLEARING The state is entered when the control component receives the CLEAR command. It orders the control component and device to clear the information that did lead to the ABORT state and move to STOPPED state.
  • STOPPING The control component is stopping the device, i.e. bringing it to a controlled and safe stop. The STOPPING state is entered from any state in response to the STOP command.
  • STOPPED In this state the device is stationary and powered on. It is also communicating.


The following table defines execution states and accepted commands for state changes in each execution state. The control component issues the State completed (SC) command when a previous state completes.


Current State Order State Complete (SC)
START COMPLETE RESET HOLD UNHOLD SUSPEND UNSUSPEND CLEAR STOP ABORT SC
IDLE STARTING STOPPING ABORTING
STARTING STOPPING ABORTING EXECUTE
EXECUTE COMPLETING HOLDING SUSPENDING STOPPING ABORTING
COMPLETING STOPPING ABORTING COMPLETE
COMPLETE RESETTING STOPPING ABORTING
RESETTING STOPPING ABORTING IDLE
HOLDING STOPPING ABORTING HELD
HELD UNHOLDING STOPPING ABORTING
UNHOLDING STOPPING ABORTING EXECUTE
SUSPENDING STOPPING ABORTING SUSPENDED
SUSPENDED UNSUSPENDING STOPPING ABORTING
UNSUSPENDING UNSUSPENDING STOPPING ABORTING EXECUTE
STOPPING ABORTING STOPPED
STOPPED RESETTING ABORTING IDLE
ABORTING ABORTED
CLEARING ABORTING STOPPED


Operation Mode state machine

Operation modes structure the functions of a control component. A component may realize multiple operation modes that may be selected by the component user to select the behavior of the control component and controlled devices. Different production steps supported by the same device are implemented as operation modes. The current operation mode of a control component is provided via signal OPMODE. The actual execution mode indicates the execution mode of the selected operation mode. In addition to control component specific operation modes, each control component defines the basic operation mode BSTATE, which is the basic state. Changing of operation mode may be via an order that selects the operation mode. These orders are specific to the control component, for example, the order name may be the same as the desired operation mode. Switching of operation modes is not possible in any execution state. Most control components support switching of operation modes in IDLE execution state, but switching semantics to a specific operation mode depends on the control component. Changing to a specific execution mode, e.g. COMPLETED, ABORTED, STOPPED may also yield an operation mode change. Operation modes and execution modes are therefore not independent.


Work state state machine

Signal WORKST defines the work state of a component. It contains control component specific information.


Error state state machine

BaSys 4.0 components should report exactly one error state for every occurring fault. BaSys does not define a generic fault automaton that describes the error state of a component. If a control component is in normal operation, it should communicate error state 0 (OK).

Components with concurrent behavior

Complex devices may consist of concurrent behavior. BaSys control components do need to provide the control component interface and state machines. In case of concurrent behavior in devices, an implementer has two options:

  • Development of one control component that applies internal mappings to map concurrent device behavior to control component state machines
  • Development of multiple control components that control independent aspects of the controlled device.

Control component interface

Communication endpoints realize the communication of every control component. The following figure illustrates the communication endpoints of every control component:


Basyx.ControlComponentIF.png


The meaning of communication endpoints (ports) E1-E5 are as following:

  • E1: Component service interface (upstream)
    • The component service interface provide a service-based interface to the component. Other BaSys components use this interface to invoke service of the control component.
  • E2: Signal inputs
    • Signal inputs of a control component are value-based inputs. This interface is optional. They enable direct inter-component communication. They support for example the direct exchange of safety signals and are often fixed connections that in some cases map directly to physical connections. The value of some signal inputs are available via the component service interface.
  • E3: Signal outputs
    • Signal outputs are optional value based outputs of a component. They support for example the direct exchange of safety signals and are often fixed connections that in some cases map directly to physical connections. The value of some signal outputs are available via the component service interface.
  • E4: Component service interface (downstream)
    • Group components use the component service interface (downstream) to connect to other components, and to invoke services and to read and/or change property values.
  • E5: Native device interface
    • Device components use the native device interface to interact with native devices. This communication endpoint implements any proprietary communication that is necessary to control a device, and to access its properties and services.

Virtual Automation Bus (VAB) implementation

Eclipse BaSyx connects BaSyx control components as elements to the Virtual Automation Bus (VAB), the End-to-End communication infrastructure of Eclipse BaSyx. Every BaSyx control component needs to implement the minimum VAB interface that is described in this section. The following table illustrates the minimum set of VAB attributes and operations for control components that are connected to the virtual automation bus. The predefined property groups status and occupy define properties for input and output signals that enable signal based communication with the control component. The predefined operations implement the minimum API for every control component that enables updating of its status.


Attribute (output) Technology independent signal name Description
orderList ORDERLIST List of valid operations (orders)
status/occupationState OCCST Occupation: Current occupation state
status/occupier OCCUPIER Occupation: ID of current occupier
status/lastOccupier OCCLAST Occupation: ID of previous occupier
status/exMode EXMODE Execution mode: Active execution mode
status/exState EXST Execution state: Active execution state
status/opMode OPMODE Operation mode: Active operation mode
status/workState WORKST Work state: Actual work state
status/errorState ER Error state: Actual error state
status/prevError ERLAST Error state: Previous error state
Attribute (input) Technology independent signal name Description
cmd CMD Command input signal
occupy/localOverwrite Enable local overwrite
occupy/localOverwriteFree Release local overwrite
Operations Technology independent order Description
operations/service/free(senderId:String) FREE Free component occupation if sender is occupier
operations/service/occupy(senderId:String) OCCUPY Occupy component
operations/service/priority(senderId:String) PRIO Occupy component with priority
operations/service/auto AUTO Change to execution mode AUTO
operations/service/semiauto SEMIAUTO Change to execution mode SEMIAUTO
operations/service/manual MANUAL Change to execution mode MANUAL
operations/service/start START Start selected operation mode
operations/service/reset RESET Reset selected operation mode
operations/service/hold HOLD Hold operation
operations/service/unhold UNHOLD Unhold operation
operations/service/suspend SUSPEND Suspend operation
operations/service/unsuspend UNSUSPEND Unsuspend operation
operations/service/abort ABORT Abort operation
operations/service/stop STOP Stop operation
operations/service/clear CLEAR Clear aborted execution state
operations/service/reset RESET Reset control component from stopped state
operations/service/bstate BSTATE Enter basic operation mode


Technology mappings

The BaSys 4.0 project has defined technology mappings for the device interface that are implemented by the Virtual Automation bus. BaSyx users may define additional technology mappings for other types of networks and bus systems, and include them by creating BaSyx Virtual Automation Bus (VAB) Gateways.


OPC-UA

This section defines a mapping of the BaSys 4.0 control component interface to OPC-UA. Our OPC-UA mapping maps VAB operations to OPC-UA operations and VAB attributes to OPC-UA attributes. The implicit path element operations/ is omitted for OPC-UA. Eclipse BaSys will provide a generic BaSyx OPC-UA gateway component to connect control components with the OPC-UA interface from this section to the virtual automation bus and therefore enables accessing of the control component status and services. Developers therefore only need to implement this OPC-UA object structure to ensure a BaSyx conforming component.

OPC-UA node type use
ControlComponent/Control/cmd write
ControlComponent/Control/orderList read
ControlComponent/Control/status/occupationState read
ControlComponent/Control/status/occupier read
ControlComponent/Control/status/lastOccupier read
ControlComponent/Control/status/exMode read
ControlComponent/Control/status/exState read
ControlComponent/Control/status/opMode read
ControlComponent/Control/status/workState read
ControlComponent/Control/status/errorState read
ControlComponent/Control/status/prevError read
ControlComponent/Control/status/localOverwrite write
ControlComponent/Control/status/localOverwriteFree write
ControlComponent/Control/status/free operation
ControlComponent/Control/status/occupy operation
ControlComponent/Control/status/priority operation
ControlComponent/Control/status/auto operation
ControlComponent/Control/status/semiauto operation
ControlComponent/Control/status/manual operation
ControlComponent/Control/status/start operation
ControlComponent/Control/status/reset operation
ControlComponent/Control/status/hold operation
ControlComponent/Control/status/unhold operation
ControlComponent/Control/status/suspend operation
ControlComponent/Control/status/unsuspend operation
ControlComponent/Control/status/abort operation
ControlComponent/Control/status/stop operation
ControlComponent/Control/status/clear operation
ControlComponent/Control/status/reset operation
ControlComponent/Control/status/bstate operation

Additional gateways may implement additional mapping schemes, and may include control components and devices with non-conforming interfaces by implementing component and device specific mappings that provide a conforming façade to the VAB.

BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation

Back to the top