BaSyx / Documentation
The Eclipse BaSyx middleware
The BaSyx middleware groups Industrie 4.0 components around an end-to-end communication medium, the virtual automation bus (VAB). The VAB implements an object oriented communication approach that exports all information and services as objects with a unique identifier that are connected to one virtual and homogeneous communication network, even if it is realized by multiple physical networks. The VAB therefore defines five virtual communication primitives that are mapped to concrete physical networks. VAB primitives provide a unified way to access properties and operations of VAB objects in a network and machine independent manner. VAB gateways realize inter-network communication by mapping the comminication primitives to network specific telegrams, and this way enable end-to-end communication. Gateways furthermore may be used to integrate legacy devices by implementing a VAB interface for them.
The graphic below illustrates an architecture overview on the BaSyx middleware, its component types, and predefined component interfaces:
BaSys 4.0 conforming production systems consist of the following types of communicating Industrie 4.0 components:
|Control component||Control components realize BaSys 4.0 conforming service based Industrie 4.0 interfaces to assets. Assets may be devices, e.g. PLC controllers, sensors, actuators, but can represent any asset that realizes services or provide information, which also includes for example human workers. Control components provide a service based interface with callable services that e.g. drill a hole into a work piece. They define how a specific service is implemented, but do not decide about the orchestration of services, i.e. a control component does not decide when and if a particular service is called.||Core|
|Group component||Group components implement higher-level services that use services of other control and group components. Similar to control components, group component services provide the implementation of services but do not decide about when and why a provided service is invoked. Service callers are other components that orchestrate services.||Core|
|Virtual Automation Bus||The virtual automation bus (VAB) is our implementation of an end-to-end communication for Industrie 4.0. It maps one communication semantic with five primitives (create/retrieve/update/delete/invoke) to different networks and protocols. This way, the VAB can bridge networks via gateways, and can also integrate legacy devices into the virtual end-to-end communication network.||Core|
|Device integration||Device integration components are VAB components that are part of devices and communicate with the VAB. Device manager components for example connect native status data to VAB objects and upload Asset Administration Shells (AAS) and Sub Models of their device to AAS servers.|
|Gateway||Virtual Automation Bus protocol gateways bridges communication networks to enable inter-network communication. Every gateway needs to provide a mapping of all of the five BaSys communication primitives to its supported protocols to enable end-to-end communication. Gateways can be cascaded to bridge multiple networks.|
|Asset Administration Shell||An Asset Administration Shell (AAS) is a digital object that represents a physical or non-physical entity. It provides common meta data about its entity and enables access to Asset Administration Shell sub models. Asset Administration Shells are provided by Asset Administration Shell providers to the Virtual Automation Bus.|
|Asset Administration Shell Submodels||Asset Administration Shell submodels are part of Asset Administration Shells. They consist of (optionally nested) properties and operations with a defined meta model. AAS submodel providers provide different kinds of data as AAS submodels and hide the technology that is necessary to access native data sources. Asset Administration Shell submodel providers are implemented for example for configuration property files, SWL data bases, file systems, XML files, and numerous other sources of information. The BaSyx SDK provides a template implementation of an AAS sub model provider that may be used as foundation of tailored provider implementations.|
|Registry||The BaSys 4.0 Registry enables registration and lookup of Asset Administration Shells within defined system boundaries. Entities that provide Asset Administration Shells including their submodels may register and hence enable other participants to find them. The necessary information required for registration amongst others are unique identifiers for the Administration Shell and her respective Asset, endpoint information regarding the Asset Administration Shell's API and their submodel service provider.|
|Discovery||The BaSys 4.0 Discovery is a service that uses the registry to find Asset Administration Shells and Submodels. It provides additional functionalities to discover Asset Administration Shells and their Submodels based on filter criteria. These criteria are more advanced than a regular query parameter. The discovery service may provide indexing and/or crawling mechanisms to cache results from queried elements resp. find deeper information when searching.|
|Strategy / Optimization||The Strategy/Optimization component calculates production plans and production schedules that define when, and on which machine a production step for a specific product will be executed. This component is usually a domain or plant specific application component.|
|Process control||The process control component executes the production plans that the Strategy/Optimization component did create. Eclipse BaSyx will integrate for example the open source Activiti BPMN engine as process control engine.|
|Monitoring||The monitoring component enables the monitoring of the production process. It for example collects and aggregates data for analysis or pushes selected and aggregated data to a dashboard.|
In addition to these predefined component types, BaSyx users may add other application components that connect to the VAB and interact with other components and their exported VAB objects. Every VAB object has a defined and unique ID:
BaSyx defines interfaces for predefined component types. Interfaces are well-defined interaction points in the BaSys 4.0 architecture. They enable the substitution of component implementations and the development of conforming implementations by 3rd parties. BaSys 4.0 components and BaSyx components define HTTP-REST interfaces on middleware and plant levels, as well as OPC-UA and native TCP BaSyx interfaces on device level. Conforming implementations of BaSys 4.0 components need to implement at least the interfaces shown in the above figure and the following table. The BaSyx platform provides a reference implementation for core components that are necessary to create and deploy an Industrie 4.0 solution.
|Component type||Necessary provided interfaces||Interface type|
|Control component||BaSyx control component API||OPC-UA, BaSyx native|
|Group component||BaSyx control component API||OPC-UA, BaSyx native|
|Gateway||Gateway||Any to any|
|Asset Administration Shell||AAS||HTTP-REST|
|Asset Administration Shell sub models||BaSyx submodel provider API||HTTP-REST|
|Registry||BaSyx Registry API||HTTP-REST|
|Strategy / Optimization||---||HTTP-REST|
|Process Control||Process management, Process execution||HTTP-REST|
Strategy / optimization and Monitoring components are highly plant specific. These components use provided interfaces of other BaSys 4.0 components, but are not required to provide defined BaSys 4.0 interfaces.
BaSyx component types
Eclipse BaSyx implements the following ready-to-use components and component templates as Java Servlets in the package basys.components:
AAS/Sub model providers
AAS/Sub model providers provide generic Virtual Automation Bus objects, Asset Administration Shells, and/or sub models with a defined ID on the virtual automation bus.
- CFG Submodel provider
- RAW AAS/Submodel provider
- SQL Submodel provider
- XQuery Submodel provider
- under construction: XML AAS/Submodel provider
Registry providers enable Industrie 4.0 devices to register asset administration shells (AAS), and AAS users to lookup a specific asset administration shell.
- Precompiled registry
- File based registry
- SQL based dynamic registry
Control component templates (Java/C++)
Control components implement and connect production services to the Industrie 4.0 infrastructure. Device control components usually integrate production devices into the Industrie 4.0 infrastructure, but may also connect to worker guidance systems and therefore integrate services provided by human workers. Group control components use other control components to provide higher-level services.
- under construction: control component template (Java/C++)
BaSyx SDK Architecture
The documentation of the BaSyx SDK architecture is provided on its own documentation page.
|BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation|