Skip to main content
Jump to: navigation, search

BaSyx / Documentation / API / ControlComponent

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