Skip to main content
Jump to: navigation, search

Difference between revisions of "BaSyx / Documentation"

m (Proper image formatting)
Line 1: Line 1:
 +
= BaSyx Documentation=
 +
 +
This page provides developer documentation regarding the BaSyx open-source platform.
 +
 +
 
== Architecture overview ==
 
== Architecture overview ==
  
Line 101: Line 106:
  
 
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.
 
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.
 +
 +
 +
== Device integration ==
 +
 +
We support three strategies for integrating devices with a BaSys 4.0 production architecture:
 +
* 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.
 +
* 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.
 +
* 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.
 +
 +
 +
[[file:BaSyx.DeviceIntegration.png|center|1024px]]
 +
 +
 +
== 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.
 +
 +
 +
[[file:BaSyx.SubModelTypes.png|center|800px]]
 +
 +
 +
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.

Revision as of 11:20, 28 August 2018

BaSyx Documentation

This page provides developer documentation regarding the BaSyx open-source platform.


Architecture overview

The BaSys 4.0 project defines the following main component types:


Component type Description
Control component Provides a conforming BaSys 4.0 service based interface that enables access to device capabilities.
Group component Provides higher-level services that use services of other control and group components.
Gateway Protocol gateway that bridges five BaSys communication primitives between protocols to enable end-to-end communication.
Asset Administration Shell 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.
Asset Administration Shell sub models 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.
Registry / Discovery The registry/discovery component enables registration and lookup of Asset Administration Shells.
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.
Process control The process control component executes the production plans that the Strategy/Optimization component did create.
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 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.Architecture Overview.png


Component interfaces

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.


BaSyx.Architecture Interfaces.png


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.


Component type Necessary provided interfaces Interface type
Control component RTE Management, Service status, Service selection, Service invocation OPC-UA, BaSyx native
Group component RTE Management, Service status, Service selection, Service invocation OPC-UA, BaSyx native
Gateway Gateway Any to any
Asset Administration Shell AAS HTTP-REST
Asset Administration Shell sub models Sub model HTTP-REST
Registry / Discovery Discovery, Registry HTTP-REST
Strategy / Optimization --- HTTP-REST
Process Control Process management, Process execution HTTP-REST
Monitoring --- 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.


Device integration

We support three strategies for integrating devices with a BaSys 4.0 production architecture:

  • 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.
  • 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.
  • 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.


BaSyx.DeviceIntegration.png


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.


BaSyx.SubModelTypes.png


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.

Back to the top