BaSyx / Introductory Examples / Java / Step 1

Step 1: Creating the digital models

The first step in creating adigital manufacturing architecture is to create the sub models for all real-world assets, and to devise the overall system architecture. Real-world assets are both physical assets, e.g. products and devices, and also non-physical assets, such as processes, orders, and possibly deadlines. This architecture defines public properties of assets, and offered services. It also defines the deployment of main BaSyx components. The figure below illustrates a common, basic BaSyx deployment that fits very well as nucleus for most settings.

This basic deployment consists of the most important components for running Eclipse BaSyx only. The registry tracks available Asset Administration Shells and Sub models, the AAS server provides access to AAS and sub model instances through a unified API (cf. Interface and AAS). Both components are deployed as containers on host systems that are part of the IT infrastructure (Server) of the company.

A real BaSyx deployment will use additional AAS servers and sub model locations to balance the load, and to enable data processing close to the process. The figure below illustrates the deployment that we will be used for the next steps of this example. In addition to the basic architecture, a client application is deployed on an office PC, and the oven sub model is deployed to an edge device close to the process. This enables the processing of raw data on site, and will only report aggregated data to the IT infrastructure. The oven is an existing oven that does not provide any AAS or Industry 4.0 functionality. Therefore, the AAS needs to implement the communication with the oven, and it needs to request temperature data when required.

The oven will be represented by an AAS with one sub model: the oven sub model. The oven sub model provides access to the oven temperature and enables a very basic controlling of the oven.

Every AAS has a generic structure. All specific information is provided by sub models. These contain therefore the domain specific knowledge. Sub models enable access to data and services. Depending on the kind of sub model, this may be static data, e.g. a digital nameplate, or dynamic data and services. In our example, the oven defines a single sub model that enables to activation and de-activation of the heater, and access to the current temperature of the oven. The following illustrates the structure of the oven sub model:

properties:

id: "heater01"

temperature

operations:

deactivateOven // *Function* for deactivating the oven,

activateOven // *Function* for activating the oven