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.
Difference between revisions of "BaSyx / Documentation / API / ControlComponent"
m (Added references section.) |
m (→ES profile: Changed order of BASYS ES profile value (IPSMS) to match the example.) |
||
| Line 602: | Line 602: | ||
| 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values] || Undefined | | 0 - 2 || UNKNOWN, NONE, ANY || See [[#Common profile values|common profile values] || Undefined | ||
|- | |- | ||
| − | | 3 || | + | | 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 || | + | | 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 || | + | | 5 || MTP || MTP state machine || MTP Part 4<ref name="MTP">VDI/VDE/NAMUR 2658 Part 4 - Modelling of module services</ref> |
|- | |- | ||
| − | | 6 || | + | | 6 || OPCUA || OPC UA program state machine || OPC UA Part 10<ref name="OPCUA-Part10">IEC 62541 Part 10 – Programs</ref> |
|- | |- | ||
| − | | 7 || | + | | 7 || BASYS || Subset of PackML (Start, Stop, Reset) || PackML without held, suspended, aborted and corresponding active states.<!-- BaSys IPSMS specification --> |
|- | |- | ||
|} | |} | ||
Revision as of 10:29, 9 January 2020
| Overview | Interface | Implementation |
Contents
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.
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).
Control component profiles
The abstract concept of control components and their state machines may be realised in technology specific ways or focussed on certain aspects.
For example an occupation might not be necessary or a smaller 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 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 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.
BaSys control components may be described by the following profiles:
- SI - Service Interface Profile
- Describes how the offered 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 - Occupation Profile
- Describes whether a occuption is necessary.
- Variants may describe whether a occupation with priority or local is possible.
- EM - Execution Modes Profile
- Describes whether different execution modes are possible.
- Variants may describe which modes are possible and how they are called.
- ES - Execution States Profile
- References the used execution states and their transitions.
- May describe variants or subsets of a full execution state state machines.
- OM - Operation Modes Profile
- 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.
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 figure.
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.
| 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. |
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.
| 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.
| Value | Name | Description | Possible EXMODE values |
|---|---|---|---|
| 0 - 2 | UNKNOWN, NONE, ANY | See [[#Common profile values|common profile values] | Undefined |
| 3 | MANUAL | Only one occupier | AUTO, MANUAL |
| 4 | SEMIAUTO | Priority possible | OCCUPIED, PRIO |
| 5 | SIMULATE | Local overwrite | OCCUPIED, PRIO, LOCAL |
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. [1] 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.
| 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[2] |
| 4 | ISA88 | ISA88 state machine | ANSI/ISA-88.00.01-2010[3] |
| 5 | MTP | MTP state machine | MTP Part 4[4] |
| 6 | OPCUA | OPC UA program state machine | OPC UA Part 10[5] |
| 7 | BASYS | Subset of PackML (Start, Stop, Reset) | PackML without held, suspended, aborted and corresponding active states. |
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.
| 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
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:
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.
Service interface profile
The control component service interface E1 may be realised in various ways.
Basys classifies different realisations via 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 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.
| SI value | Name | Usage in Basys | Activation mechanism | Aggregated state represenation | Utiliziation recommendation |
|---|---|---|---|---|---|
| 0 - 2 | UNKNOWN, NONE, ANY | See 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.
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.
References
- ↑ 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.
- ↑ ISA-TR88.00.02-2008 Machine and Unit States: An Implementation Example of ISA-88.
- ↑ ISA-S88 Part 1 – Batch Control Models and Terminology (IEC 61512-1)
- ↑ VDI/VDE/NAMUR 2658 Part 4 - Modelling of module services
- ↑ IEC 62541 Part 10 – Programs
| BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation |