Eclipse BaSyx: A Middleware for Industry 4.0

The Eclipse BaSyx project is the open source result of the German research project "BaSys 4.0", which is funded by the Ministry for Education and Research (grant no. 01IS16022). Drawing inspiration from Autosar, BaSyx is a middleware in the sense that it sits on top of existing communication standards used in industrial automation, providing an abstraction/compatibility layer to industrial applications. While the project has wrapped up, its successor, "BaSys 4.2", kicked off this month and will conclude in three years.

What is Industry 4.0?

Industry 4.0 refers to the current digitization of Industrial automation as a 4th industrial revolution after mechanization, electrification, and computerization, respectively. Other names used are Industrial IoT or just Industrial Internet. Industry 4.0 is not a single concept, but a collection of concepts and objectives:

• Striving for a flexible, reconfigurable production that enables quick changes and small lot sizes.
• Open, highly interconnected automation systems that allow for data access across several layers of the automation pyramid, and even factories.
• A general higher infusion of modern information technology concepts in automation (like Big Data).
• A reflectance of the ongoing paradigm shift from embedded systems to cyber-physical systems.

However, addressing these objectives is difficult, if not impossible, with the typical IT infrastructure as it is found in today's shop floors. It lacks the required flexibility, interoperability, and abstraction. With BaSyx, we intend to remedy this situation by providing a service-oriented architecture through a standardized interface and a virtual bus (called Virtual Automation Bus) on top of the existing network infrastructure. That way, both modern (e.g. OPC UA), as well as legacy systems, are supported. The universal interface in a BaSyx network is the Asset Administration Shell, which is the digital representative of a real-life object. Altogether, this approach is supposed to enable a service-based production.

Asset Administration Shells

The Asset Administration Shell (AAS) is a concept currently standardized by the German Industry. The core idea is that every asset in the production process, e.g. a machine, a production line, a worker, or a product, has such an administration shell, which

• contains and/or points to every digital information available for that asset, and
• allows accessing capabilities of an asset via service calls

An asset, together with its AAS, is called an Industry 4.0 component. An AAS is organized into sub-models, which contain data and services of a specific aspect of an asset. Some examples of possible submodels are

• The geometric properties of an asset
• The topology of an asset composed of sub-assets, e.g. a production line
• Formulas and/or simulation models describing the physical process implemented by the asset
• User documentation

Users are able to define their own submodels to custom tailor the asset administration shells to their application. Additionally, there is a set of suggested submodels provided by BaSyx. For example, each asset can have a service submodel, containing all provided services. This service submodel can then be used to enable a service-based production by providing a unified means of accessing the manufacturing capabilities of an asset.

The AAS is the central point of access in the BaSyx Middleware. For example, if an application wants to use a certain capability of a certain device, it calls the corresponding service of the device's AAS. Explorative approaches are also supported, e.g. an application can browse through the services listed in the AAS, or search for a specific one. In addition, via a directory service, an application can search for administration shells that provide certain services.

The BaSyx middleware features an open source implementation of a distributed Asset Administration Shell. That means the information provided by an AAS can reside in different places in the network; e.g. different submodels might have different locations, or extensive history data of several AAS might be put on a dedicated server.

The connection between an application and an AAS, between an AAS and a remote submodel, and between an AAS and a device is established in the background via the Virtual Automation Bus.

The Virtual Automation Bus

There are many different protocols in the manufacturing domain. There are relatively new approaches, e.g. OPC UA, but also legacy protocols like Profibus. To be able to integrate all devices within a plant with each other, there has to be an integration of this heterogeneous communication system. The Virtual Automation Bus (VAB) is inspired by the Virtual Function Bus in Autosar. It provides end-to-end communication, possibly bridging several protocols. Thus, it allows accessing properties and operations provided by the VAB participants. Additionally, it enables the connection between legacy devices and state-of-the-art applications.

To be able to provide end-to-end communication between devices potentially using different protocols, two key components are used. A Directory Service, with a known and statically configured address, allows the registration and lookup of VAB members through their unique ID. A lookup operation returns the path to the asset, i.e. its address within the VAB. Since various protocols can be used, it is possible that this address does not directly point to the asset but instead to the second VAB key component, the Gateway. Gateways perform the translation between the different protocols using an intermediate language.

This intermediate language is very similar to the CRUD approach known from persistent storage. Additionally, it is extended to allow natively invoking operations to support a service-based production.

The following primitives are supported by the VAB: Create, Delete, Read, Update and Invoke. These primitives are mapped to existing protocols, e.g. HTTP/REST. For example, an Invoke primitive translates to an HTTP-POST while a Get primitive is translated to an HTTP-GET.

Legacy Support

Starting in green field is very rare; typically, there is a mixture of old, non-Industry 4.0 ready devices, and newer device, i.e. a brown field. Thus, it is necessary to provide a migration path for older devices.

BaSyx supports the integration of legacy devices through the concept of cut-in devices. These cut-in devices provide a mapping of the VAB primitives to the legacy protocol. For example, a mapping between a native protocol message and the desired property can be created statically.

Conclusion

With its Asset Administration Shell approach combined with the Virtual Automation Bus concept, BaSyx intends to enable the Industry 4.0 scenarios envisioned today. In the BaSyx GIT repo, you will find SDKs for Java, C++, and C#, with the Java version being the most advanced at the moment.

You can find more technical information in the BaSyx Wiki. More information about the research project BaSys 4.0 and our project partners is available on http://www.basys40.de/ (in German).