Skip to main content
Jump to: navigation, search

Difference between revisions of "BaSyx / Documentation"

m (Updates links)
 
(40 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== BaSyx Documentation ==
+
== The Eclipse BaSyx Middleware ==
  
This page provides an architecture overview for developers regarding the BaSyx open-source platform. The following subsequent pages provide in-depth information regarding specialized aspects:
+
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 communication 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 of the BaSyx middleware and its various components:
  
''' BaSyx interfaces '''
+
[[file:BaSyx.Architecture_Overview.png|center|1024px]]
[[Basyx.Discovery|BaSyx discovery API]]
+
[[BaSyx.Submodel|BaSyx submodel provider API]]
+
  
''' BaSyx end-to-end communication '''
 
[[BaSyx.VAB|BaSyx Virtual Automation Bus for End to end communication]]
 
 
''' BaSyx runtime environment / device interfaces '''
 
 
 
 
== Architecture overview ==
 
 
The BaSys 4.0 project defines the following main component types:
 
  
 +
BaSys 4.0 compliant systems consist of the following core and optionally extended components:
  
 
{| class="wikitable"
 
{| class="wikitable"
 +
|-
 +
! colspan="3" | Plattform Industrie 4.0 compliant components
 
|-
 
|-
 
! Component type
 
! Component type
 
! Description
 
! Description
 +
! Type
 
|-
 
|-
| Control component
+
| [[BaSyx_/_Documentation_/_AssetAdministrationShell|Asset Administration Shell]]
| Provides a conforming BaSys 4.0 service based interface that enables access to device capabilities.
+
| An Asset Administration Shell is a "standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. It identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective
 +
assets." (Details of the Asset Administration Shell, 2018, p. 13, [https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/2018-verwaltungsschale-im-detail.pdf])
 +
!style="background-color:green;color:white" | Core
 
|-
 
|-
| Group component
+
| [[BaSyx_/_Documentation_/_API_/_Submodel|Asset Administration Shell Submodels]]
| Provides higher-level services that use services of other control and group components.
+
| "A Submodel defines a specific aspect of the asset represented by the Asset Administration Shell. A Submodel is used to structure the virtual representation and technical functionality of an Administration Shell into distinguishable parts. Each Submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels types. Submodels can have different life-cycles." (Details of the Asset Administration Shell, 2018, p. 46, [https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/2018-verwaltungsschale-im-detail.pdf])
 +
!style="background-color:green;color:white" | Core
 
|-
 
|-
| Gateway
+
| [[BaSyx_/_Documentation_/_API_/_Registry|Registry]]
| Protocol gateway that bridges five BaSys communication primitives between protocols to enable end-to-end communication.
+
| 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.
 +
!style="background-color:green;color:white" | Core
 
|-
 
|-
| Asset Administration Shell
+
| Discovery
| An Asset Administration Shell (AAS) is a digital object that represents a physical or non-physical entity. It stores all relevant data and provides access to operations through its sub models.
+
| 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.
 +
!style="background-color:green;color:white" | Core
 +
|-
 +
! colspan="3" | BaSys components
 +
|-
 +
! Component type
 +
! Description
 +
! Type
 +
|-
 +
| [[BaSyx_/_Documentation_/_ControlComponent|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.
 +
!style="background-color:green;color:white" | Core
 
|-
 
|-
| Asset Administration Shell sub models
+
| [[BaSyx_/_Documentation_/_ControlComponent|Group component]]
| Sub models are part of one Asset Administration Shells. They consist of (optionally nested) properties and operations. AAS sub model providers provide different kinds of data as AAS sub models.
+
| 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.
 +
!style="background-color:green;color:white" | Core
 
|-
 
|-
| Registry / Discovery
+
| [[BaSyx_/_Documentation_/_VAB|Virtual Automation Bus]]
| The registry/discovery component enables registration and lookup of Asset Administration Shells.
+
| 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.
 +
!style="background-color:green;color:white" | Core
 +
|-
 +
| [[BaSyx Device integration|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.
 +
!style="background-color:orange;color:white" | Extended
 +
|-
 +
| [[BaSyx_/_Documentation_/_Gateway |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.
 +
!style="background-color:orange;color:white" | Extended
 
|-
 
|-
 
| Strategy / Optimization  
 
| 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.
+
| 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. 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.
 +
!style="background-color:orange;color:white" | Extended
 
|-
 
|-
 
| Process control
 
| Process control
| The process control component executes the production plans that the Strategy/Optimization component did create.
+
| 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.
 +
!style="background-color:orange;color:white" | Extended
 
|-
 
|-
 
| Monitoring
 
| 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.
 
| 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.
 +
!style="background-color:orange;color:white" | Extended
 
|}
 
|}
  
 +
In addition to these components, BaSyx users may add other application specific components that connect to the network via an exposed endpoint depending on the communication technology (HTTP, OPC UA, BaSyx native) used.
  
The graphic below illustrates the components of a BaSys 4.0 production system. Components connect to a virtual end-to-end communication medium that in fact may be realized with different networks and protocols. Communication is via defined primitives that are mapped to each protocol in a specific manner. Gateways bridge between protocols and enable a virtual end-to-end communication.
+
== BaSyx Identification Naming Convention ==
 +
BaSys provides a unified way to identify types and instances regardless whether it is an information model (Submodel, Concept Description, Data Element, etc.) or an asset type resp. asset instance. These identifiers can be used as unique identifier for Asset Administation Shells and Assets as well as for semantic references within the meta-model elements of the Asset Administration Shell:
  
 +
* [[BaSyx_/_Documentation_/_Identification|BaSyx URI ID schema]]
  
[[file:BaSyx.Architecture_Overview.png|center|1024px]]
+
== BaSyx Components ==
  
 +
BaSyx defines interfaces for all components contained in the architecture overview above. Interfaces are well-defined descriptions of the interaction pattern (contract) and the necessary information models (payload) for the interaction between communication participants. All BaSyx components define at least an HTTP/REST interface on middle-ware and application level. On field device level, OPC UA as well as native BaSyx/TCP are applicable for component interfaces.
  
== Component interfaces ==
+
Compliant implementations of BaSyx components need to implement at least the interfaces depicted in the following table. BaSyx provides reference implementations for core components that are necessary to create and deploy an Industrie 4.0 solution.
 
+
 
+
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.
+
 
+
 
+
[[file:BaSyx.Architecture_Interfaces.png|center|1024px]]
+
 
+
 
+
BaSys 4.0 conforming components need to implement 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.
+
  
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Component type
+
! Component
! Necessary provided interfaces
+
! Provided Interfaces
! Interface type
+
! Available Technologies
 
|-
 
|-
 
| Control component
 
| Control component
| RTE Management, Service status, Service selection, Service invocation
+
| [[BaSyx_/_Documentation_/_ControlComponent|BaSyx control component API]]
 
| OPC-UA, BaSyx native
 
| OPC-UA, BaSyx native
 
|-
 
|-
 
| Group component
 
| Group component
| RTE Management, Service status, Service selection, Service invocation
+
| [[BaSyx_/_Documentation_/_ControlComponent|BaSyx control component API]]
 
| OPC-UA, BaSyx native
 
| OPC-UA, BaSyx native
 
|-
 
|-
Line 91: Line 107:
 
|-
 
|-
 
| Asset Administration Shell
 
| Asset Administration Shell
| AAS
+
| [[BaSyx_/_Documentation_/_AssetAdministrationShell|BaSyx Asset Administration Shell Service Provider API]]
 
| HTTP-REST
 
| HTTP-REST
 
|-
 
|-
| Asset Administration Shell sub models
+
| Asset Administration Shell Submodels
| Sub model
+
| [[BaSyx_/_Documentation_/_API_/_Submodel|BaSyx Submodel Service Provider API]]
 
| HTTP-REST
 
| HTTP-REST
 
|-
 
|-
| Registry / Discovery
+
| Registry
| Discovery, Registry
+
| [[BaSyx_/_Documentation_/_API_/_Registry|BaSyx Registry API]]
 
| HTTP-REST
 
| HTTP-REST
 
|-
 
|-
Line 116: Line 132:
  
  
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.
+
Eclipse BaSyx implements the following ready-to-use components:
  
== Virtual Automation Bus ==
+
'''Asset Administration Shell & Submodel Providers'''
One challenge of Industrie 4.0 is to integrate heterogeneous devices with possibly different communication protocols into a complete system.
+
BaSys 4.0 solves this problem by utilizing a Virtual Automation Bus (VAB). The VAB defines the following five primitives:
+
{| class="wikitable"
+
|-
+
! Primitive
+
! Semantics
+
|-
+
| Get
+
| Retrieves an element
+
|-
+
| Set
+
| Sets the value of an element
+
|-
+
| Create
+
| Creates a new element
+
|-
+
| Delete
+
| Deletes an existing element
+
|-
+
| Invoke
+
| Invokes a method
+
|}
+
  
Each protocol may be mapped to the VAB by creating a mapping of this five primitives to its native communication techniques.
+
Asset Administration Shell and Submodel providers provide generic Virtual Automation Bus objects, Asset Administration Shells, and/or Submodels with a defined ID on the network.  
As an example, in the world of HTTP the delete primitive may be mapped to a HTTP-Delete request. Communication between networks using different protocols is supported by gateways translating between the protocols.
+
* [[BaSyx CFG sub model provider|CFG Submodel provider]]
 +
* [[BaSyx RAW AAS/Submodel provider|RAW AAS/Submodel provider]]
 +
* [[BaSyx SQL Submodel provider|SQL Submodel provider]]
 +
* [[BaSyx XQuery Submodel provider|XQuery Submodel provider]]
 +
* ''under construction: XML AAS/Submodel provider''
  
The benefit of this approach is a reduced implementation effort to bridge different communication technologies. Instead of having to translate from every protocol to every protocol (NxM) it is possible to use the VAB primitives as intermediate and reduce the complexity (N+M).
 
  
== Device integration ==
+
'''Registry Providers'''
  
We support three strategies for integrating devices with a BaSys 4.0 production architecture:
+
Ready-to-use reference implementations of the [[BaSyx.Registry|BaSyx Registry API]] enable Industrie 4.0 components to register their Asset Administration Shells resp. users/applications to find those in a BaSyx compliant manner.
* Smart SPS/PLC are PLC controllers with sufficiently smart RTE that enable the development of BaSys 4.0 control components and conforming BaSys 4.0 interface implementation on the device.
+
* Pre-compiled Registry (Local, Cloud & On-Premises via Docker)
* Smart Devices are devices that directly provide a BaSys 4.0 conforming interface. They implement the BaSys 4.0 interface implementation on the device, e.g. on an embedded microcontroller.
+
* Simple File-based Registry (Local & Docker)
* BaSys 4.0 interface devices connect existing legacy devices with proprietary connectors to a BaSys 4.0 production system. Interface devices implement the BaSys 4.0 conforming interface towards the production system, and connect to the device using its native communication technology and protocol. Service invocation is therefore triggered, for example, by calling an OPC-UA operation, by setting an OPC-UA variable, or even by changing a Modbus value. The concrete communication protocol to the device depends on the device to be integrated.
+
* SQL-based Dynamic Registry
  
  
[[file:BaSyx.DeviceIntegration.png|center|1024px]]
+
'''Virtual Automation Bus Providers'''
  
 +
Low-level providers provide generic Virtual Automation Bus objects and do not make an assumption on the structure. Thus, all types of objects can be offered by such a provider.
 +
* [[BaSyx_/_Documentation_/_HashMap_Provider_|HashMap provider]]
 +
* [[BaSyx_/_Documentation_/_FileSystem_Provider_|FileSystem provider]]
 +
* [[BaSyx_/_Documentation_/_Lambda_Provider_|Lambda provider]]
  
== BaSys 4.0 sub model types ==
 
  
Asset Administration Shells consist of sub models. Sub models contain (optionally nested) properties and operations. Every sub model conforms to a sub model type. Sub model types may be defined specifically for a sub model. This is usually the case when a sub model is specific to one environment, or to one plant. BaSys 4.0 also predefines sub model types for specific sub models. These sub model types are either recommendations or mandatory. Recommended sub model types are not mandatory to use, but they are considered good designs and are provided as guideline. Mandatory sub models need to be implemented in a conforming manner to ensure correct operation.
+
'''Control Component Templates'''
  
 +
<<under construction>>
  
[[file:BaSyx.SubModelTypes.png|center|800px]]
+
== BaSyx SDK Architecture ==  
 
+
The documentation of the BaSyx SDK architecture is provided on its own [[BaSyx:BaSyx.Documentation.SDK|documentation page]].
 
+
Currently, The BaSys 4.0 project defines three sub model types:
+
* Topology: This sub model type defines a common sub model structure for the topology information of plants, production lines, and aggregated devices. 
+
* Capability: This sub model type defines a common sub model structure for the description of (device) capabilities. Capability definitions are required for the description of device provided capabilities, and of capabilities required for product production steps.
+
* Identification: Virtual and physical production assets may carry different identities. For example, the same asset may be known by different identities to different stakeholders. Identifies may be globally unique or only local identities, such as serial numbers.
+
 
+
== BaSys 4.0 control and group components ==
+
 
+
The Device Layer of a Basys4.0 compliant production systems contains Control Components and Group Components, which reflect the new skill-based and hierarchical programming approach of such a system. A Control Component represents the lowest layer of the plant and directly connects to the controlled process via an Input/Output (IO) interface and a network interface to the Group Components on the next hierarchical layer. Group Components are typically not directly wired to the physical process under control. Instead, they serve as orchestrators for the Control Components and provide a network interface to the underlying Control Components and another network interface for the connection to other Group Components and the Basys4.0 compliant Middleware.
+
 
+
=== BaSys 4.0 control component ===
+
 
+
Control Components are typically programmed via standardized PLC programming paradigms. The two fundamentally different approaches are the cyclic execution model of Function Blocks (FB) of the IEC61131-3 and the event-based execution of FBs according to IEC61499. IEC61131-3 defines five languages for programming PLCs and its standardization was first published in December 1993 (the most recent standard was published in February 2013). 3S is for example implementing an IEC61131-3 development and runtime environment called CodeSys. The standardization of IEC61499 started after the standardization of IEC61131, by the same standardization group, which previously worked on IEC61131 with the main objectives of solving portability, configurability and interoperability for industrial control applications that IEC61131 does not solve. The most recent version of the IEC61499 standard was published in November 2012. The standardization group added events to the interface of the FBs and therefore changed the execution semantics. IEC61499 targets distributed industrial automation systems in contrast to IEC61131, which is focused on centralized systems. Eclipse 4diac is an open-source implementation of an IEC61499 compliant development and runtime environment.
+
 
+
A Basys4.0 Control Component's IO interface connects the device to the sensors and actuators of the process in the field level (see figure). These IOs are digital or analog signals which are treated differently by each device manufacturer.  Therefore, porting an existing runtime environment to a new PLC usually includes the adaptation of the runtime to the IO interface of the device. The connection to the next hierarchical layer (the Group Components still on the Device Level, or the different components in the Basys4.0 Middleware) is achieved by a network interface. Here, BaSyx proposes to use standardized network protocols as http/Rest or OPC UA. However there exist plenty of different proprietary network protocols and fieldbusses in state-of-the-art production systems.  Usually each of the big market players provide their own fieldbus which cannot interact out of the box with fieldbusses of other manufacturers. This lack of interoperability can be tackled using BaSyx, which provides the possibility to introduce gateways from any kind of protocol to the afore mentioned standardized protocols on which BaSyx usually operates.  
+
 
+
Examples for control components could for example be vertical and horizontal axis' that provide the basic skill "go-to-position" or a gripper that offers the basic skill "grip". These separate skills are then advertised via the network interface to Group Components and the Middleware.
+
 
+
=== BaSys 4.0 group component ===
+
 
+
BaSys4.0 compliant Group Components significantly differ from Control Components because they do not have an IO interface to the process under control, but rather two network interfaces, one to the underlying Control Component(s) and one for connecting to other Group Components or the services in the BaSys4.0 Middleware. The function of such a component is not to directly interact with the process, but to coordinate and orchestrate the Control Components, which are then interacting with the process. Therefore, a Group Component combines the different basic skills into composed skills and advertises these composed skills via OPC UA to upper layer Group Components or the Middleware. An example composed skill of an orchestrating Group Component of the Pick&Place station would be "assemble", which combines the basic skills "go-to-position" and "grip" in the appropriate order such that it achieves the desired task of assembling a product.
+
 
+
{| 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]]
+
|}
+

Latest revision as of 10:03, 12 March 2020

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 communication 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 of the BaSyx middleware and its various components:

BaSyx.Architecture Overview.png


BaSys 4.0 compliant systems consist of the following core and optionally extended components:

Plattform Industrie 4.0 compliant components
Component type Description Type
Asset Administration Shell An Asset Administration Shell is a "standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. It identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective

assets." (Details of the Asset Administration Shell, 2018, p. 13, [1])

Core
Asset Administration Shell Submodels "A Submodel defines a specific aspect of the asset represented by the Asset Administration Shell. A Submodel is used to structure the virtual representation and technical functionality of an Administration Shell into distinguishable parts. Each Submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels types. Submodels can have different life-cycles." (Details of the Asset Administration Shell, 2018, p. 46, [2]) Core
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. Core
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. Core
BaSys components
Component type Description Type
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. Extended
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. Extended
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. 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. Extended
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. Extended
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. Extended

In addition to these components, BaSyx users may add other application specific components that connect to the network via an exposed endpoint depending on the communication technology (HTTP, OPC UA, BaSyx native) used.

BaSyx Identification Naming Convention

BaSys provides a unified way to identify types and instances regardless whether it is an information model (Submodel, Concept Description, Data Element, etc.) or an asset type resp. asset instance. These identifiers can be used as unique identifier for Asset Administation Shells and Assets as well as for semantic references within the meta-model elements of the Asset Administration Shell:

BaSyx Components

BaSyx defines interfaces for all components contained in the architecture overview above. Interfaces are well-defined descriptions of the interaction pattern (contract) and the necessary information models (payload) for the interaction between communication participants. All BaSyx components define at least an HTTP/REST interface on middle-ware and application level. On field device level, OPC UA as well as native BaSyx/TCP are applicable for component interfaces.

Compliant implementations of BaSyx components need to implement at least the interfaces depicted in the following table. BaSyx provides reference implementations for core components that are necessary to create and deploy an Industrie 4.0 solution.


Component Provided Interfaces Available Technologies
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 BaSyx Asset Administration Shell Service Provider API HTTP-REST
Asset Administration Shell Submodels BaSyx Submodel Service Provider API HTTP-REST
Registry BaSyx Registry API HTTP-REST
Strategy / Optimization --- HTTP-REST
Process Control Process management, Process execution HTTP-REST
Monitoring --- HTTP-REST


Eclipse BaSyx implements the following ready-to-use components:

Asset Administration Shell & Submodel Providers

Asset Administration Shell and Submodel providers provide generic Virtual Automation Bus objects, Asset Administration Shells, and/or Submodels with a defined ID on the network.


Registry Providers

Ready-to-use reference implementations of the BaSyx Registry API enable Industrie 4.0 components to register their Asset Administration Shells resp. users/applications to find those in a BaSyx compliant manner.

  • Pre-compiled Registry (Local, Cloud & On-Premises via Docker)
  • Simple File-based Registry (Local & Docker)
  • SQL-based Dynamic Registry


Virtual Automation Bus Providers

Low-level providers provide generic Virtual Automation Bus objects and do not make an assumption on the structure. Thus, all types of objects can be offered by such a provider.


Control Component Templates

<<under construction>>

BaSyx SDK Architecture

The documentation of the BaSyx SDK architecture is provided on its own documentation page.

Back to the top