The Asset Administration Shell (AAS) is an emerging concept in connection with the digital twin data management. It is a virtual representation of a physical or logical unit, such as a machine or a product. The AAS enables relevant information about this unit to be collected, processed and used to ensure efficient and intelligent production. The architectural standardization of the AAS enables communication between digital systems and is therefore the basis for Cyber Physical Systems (CPS). You can find out more about the need for digital twins in the industry here: ZEISS Digital Innovation Blog – The digital twin as a pillar of Industry 4.0
The following article focuses on the actual implementation of an example. In one scenario, we will use a reference implementation from the Fraunhofer Institute for Experimental Software Engineering IESE (BaSyx implementation of AAS v3) to establish an information exchange between two participating partners. For the sake of simplicity, both parties are based within one company and share the infrastructure.
Note: This application is also suitable for cross-company distribution. The respective security aspects are not part of this scenario.
Scenario
Factory A is a manufacturer of measuring head accessories and produces pushbuttons, among other products.
Factory B manufactures measuring heads and would like to install pushbuttons from factory A on its measuring head.
In addition to the physical forwarding of the pushbutton, information must also be exchanged. The sales department of factory A provides contact information so that the technical purchasing department of factory B can access and negotiate prices. Moreover, factory A must also provide documentation, etc.
For this exchange of information:
Contact details and
documentation
the AAS concept is to be used.
Infrastructure
In our scenario, we want to use type 2 of the Asset Administration Shell. Here, the AAS is provided on servers and there is no exchange of AASX files, but rather communication between the different services via REST interfaces.
In our scenario, the different services run within a Kubernetes cluster in Docker containers.
AAS repository, submodel repository and ConceptDescription repository are provided within one container – the AAS environment.
Technical implementation
The communication is only done via API calls to the corresponding REST interfaces of the services.
For this, we will use simple Python scripts to represent a communication in which the manufacturing factory B wants to receive information about a product (here: a pushbutton for a sensor) from the component factory A.
Procedure
Factory B only knows the asset ID of one pushbutton, but knows nothing else about this component.
Factory B uses the Asset ID to request the discovery service in order to obtain an AAS ID.
This AAS ID is used for requesting the central AAS registry, which provides the AAS repository endpoint of factory A.
Via this endpoint and the AAS ID, factory B receives the complete Asset Administration Shell including the relevant submodel IDs.
With these submodel IDs (e.g., for contact details and documentation), factory B requests the submodel registry of A and receives the submodel repository endpoints.
Factory B requests the submodel endpoints and receives the complete submodel data. This data includes the desired contact information for the buyer and complete documentation for the pushbutton asset.
The process is illustrated in detail below using UML sequence diagrams.
UML sequence: Creation of AAS registration in component factory A
Factory A is responsible for registering its own component.
Figure 1: UML sequence: Creation of the AAS registration in component factory A
UML sequence: Requesting the component data
Factory B requires data about the component and requests it from the AAS infrastructure. Here, factory B may only have access to the asset ID of the component, in our case that of the pushbutton.
Figure 2: UML sequence: Requesting the component data
Implementation
For the process described above to work, the services mentioned must be made available. Secondly, shells and submodels must be created and also stored in the registries.
Service deployment
Deployment takes place via Docker containers that run within a Kubernetes cluster. For this, each BaSyx image receives a Kubernetes deployment which starts the corresponding pods via Kubernetes replica sets. By means of port forwarding, for example, the corresponding ports are made accessible by the host. This is necessary to address the APIs according to the example Python scripts.
A relatively simple Kubernetes deployment configuration looks like this. There are four deployments, each with a replica set.
Figure 3: Kubernetes deployment configuration
Creating the AAS from factory A
Factory A would like to provide the contact details for its pushbutton component, for example.
For this, submodels are created in the AAS repository (here: in the AAS environment) and registered in the submodel registry.
Subsequently, the Asset Administration Shell is created in the AAS repository and registered in the AAS registry.
The shell reference is then added to the AAS repository.
This completes the registration process from the component factory.
Contact details requests from factory B
Factory B would like to receive the contact details and requests the various AAS services according to the workflow described above. Ultimately, the submodel data set containing the required values is obtained and can then be made available within a user interface, for example.
Conclusion
The Type 2 Asset Administration Shell is a distributed system that is based on the corresponding repositories, registries and the discovery service. In our example, we have only used a simple submodel template for contact data. However, there are far more templates available for many applications.
Communication between the services for the provision and retrieval of data is relatively straightforward, although aspects such as security were not a focus in this scenario.
The example implementation described in this article gives an idea of the immense potential of the AAS concept and encourages users to start concrete implementations.
This post was written by:
Daniel Bruegge
Daniel Brügge works as a software developer at ZEISS Digital Innovation with a focus on cloud development and distributed applications.
A cyber-physical system (CPS) is used to control a physical-technical process and, for this purpose, combines electronics, complex software and network communication, e.g. via the Internet. One characteristic feature is that all elements make an inseparable contribution to the functioning of the system. For this reason, it would be wrong to consider any device with some software and a network connection to be a CPS.
Especially in manufacturing, CPS’ are often mechatronic systems, e.g. interconnected robots. Embedded systems form the core of these systems, are interconnected by networks and supplemented by central software systems, e.g. in the cloud.
Due to their interconnection, cyber-physical systems can also be used to automatically control infrastructures that are located far away from each other or a large number of locations. These could only be automated to a limited extent – until now. Some examples of this are decentrally controlled power grids, logistics processes and distributed production processes.
Thanks to their automation, digitalization and interconnection, CPS provide a high degree of flexibility and autonomy in manufacturing. This enables matrix production systems, which support a wide range of variants at large and small quantities [1].
So far, no standardized definition has been established, as the term is used broadly and non-specifically and is sometimes used to market utopian-futuristic concepts [2].
Where did this term originate?
In recent years, innovations in the fields of IT, network technology, electronics, etc. have made complex, automated and interconnected control systems possible. Academic disciplines such as control engineering and information technology offered no suitable concept for the new mix of technical processes, complex data and software. As a result, a new concept with a suitable name was needed.
The term is closely related to the Internet of Things (IoT). Moreover, cyber-physical systems make up the technical core of many innovations that bear the label “smart” in their name: Smart Home, Smart City, Smart Grid etc.
Features of CPS
As mentioned above, there is no generally recognized definition. But the following characteristics can be destilled from the multitude of definitions:
At its core there is a physical or technical process.
There are sensors and models to digitally record the status of the process.
There is complex software to allow for a (partially) automatic decision to be made based on the status. While human intervention is possible, it is not absolutely required.
There are technical means for implementing the selected decision.
All elements of the system are interconnected in order to exchange information.
One CPS design model is the layer model according to [2]
Figure 1: Layer model for the internal structure of cyber-physical systems
Examples of cyber-physical systems
Self-controlled manufacturing machines and processes (Smart Factory)
Decentralized control of power generation and consumption (Smart Grids)
Household automation (Smart Home)
Traffic control in real time, via central or decentral control with traffic management systems or apps (element of the Smart City)
Example of an industrial cyber-physical system
This example shows a manufacturing machine that can operate largely autonomously thanks to software and interconnection, thereby minimizing idle times, downtimes and maintenance times. Let us assume that we are dealing with a machine tool for cutting as example.
Interconnected elements of the system:
Machine tool with
QR code camera for workpiece identification
RFID reader for tool identification
Automatic inventory monitoring
Wear detection and maintenance prediction
Central IT system for design data and tool parameters (CAM)
MES/ERP system
The manufacturing machine of our example is capable of identifying the workpiece and the tool. The common technologies RFID or QR code can be used for this purpose. A central IT system manages design and specification data, e.g. a computer-aided manufacturing system (CAM) for CNC machines. The manufacturing machine retrieves all the data required for processing from the central system using the ID of workpiece and tool. As a result, there is no need to enter parameters manually as the data is processed digitally throughout. The identification allows the physical layer and data layer of a cyber-physical system to be linked.
The set-up tools and the material and resource inventories available in the machine are checked on the basis of the design and specification data. The machine notifies personnel if necessary. By performing this validation before processing begins, rejects can be avoided and utilization increased.
The machine monitors its status (in operation, idle, failure) and reports the status digitally to a central system that records utilization and other operating indicators. These types of status monitoring functions are typically integrated into a Manufacturing Execution System (MES) and are now in widespread use. In our example, the machine is also able to measure its own wear and tear in order to predict and report maintenance requirements, thereby increasing its autonomy. These functions are known as predictive maintenance. All these measures improve machine availability and make maintenance and work planning easier.
Through the use of electronics and software, our fictitious manufacturing machine is capable of working largely autonomously. The role of humans is reduced to feeding, set-up, troubleshooting and maintenance; humans only support the machine in the manufacturing process.
References
[1] Forschungsbeirat Industrie 4.0, „Expertise: Umsetzung von cyber-physischen Matrixproduktionssystemen,“ acatech – Deutsche Akademie der Technikwissenschaften, München, 2022.
[2] P. H. J. Nardelli, Cyber-physical systems: theory, methodology, and applications, Hoboken, New Jersey: Wiley, 2022.
[3] P. V. Krishna, V. Saritha und H. P. Sultana, Challenges, Opportunities, and Dimensions of Cyber-Physical Systems, Hershey, Pennsylvania: IGI Global, 2015.
[4] P. Marwedel, Eingebettete Systeme: Grundlagen Eingebetteter Systeme in Cyber-Physikalischen Systemen, Wiesbaden: Springer Vieweg, 2021.
Mass individualized production, demographic change, labor shortage, and manufacturing reshoring are some global challenges that producing companies worldwide face. As a result, production sites in high-wage countries demand highly automated and flexible production systems to remain competitive. Industrial robots and custom machines have proven to be key assets and enablers in addressing some of these challenges. The flexible programming of these manufacturing systems allows tasks such as handling, transportation, and various production processes to be performed automatically with high precision, speed, and quality.
Although the benefits of such production systems have been widely demonstrated, it should be noted that there is a significant amount of integration and programming that must be considered before these systems can be run productively. In most cases, developing software for production systems requires using physical components under real conditions. However, the availability of such systems is limited in most cases for various reasons, e.g., the system is running, is being developed in parallel, or, in the worst case, does not exist. This problem causes software development to be delayed or postponed until the necessary physical components are available and integrated. In addition, programming an industrial robot is considered a non-trivial task that requires skilled operators with a good spatial understanding of the workspace and domain knowledge. Their main task is to program a sequence of motions that will ensure the completion of the production process while avoiding collisions and ensuring the process’s quality. For these reasons, industrial robot programming is still manually performed and considered challenging and resource-intensive.
At a more abstract level, these problems are common to software development in other domains. So the question arises: How do developers deal with these problems when there are no modules or interfaces? We create mocks! In a sense, mocks are nothing more than models that simulate a desired functionality. However, modeling a robot sounds a bit more complicated than mocking a database or an interface. This article aims to prove the opposite and presents a quick tutorial on how to create kinematic simulation models to make programming kinematic manufacturing systems more straightforward and efficient.
Takeaways for the reader:
Basic understanding of kinematic simulation models.
Ability to create a simple kinematic model of a manipulator (e.g., robot, rotary table, linear axes) based on Free and open-source software (FOSS) that can be used for prototyping, development, and testing purposes.
Kinematic Modelling
Reference System
Before simulating the kinematics of a robot system, some essential mathematical concepts and the common terminology used in the context of kinematic modeling must be first understood. To this purpose, consider first a minimal system consisting of a revolute joint \(j_1\) and a link \(l_1\).
The link is rigidly coupled to the joint. This means that when the joint rotates over its z-axis (frame \(B_{j_1}\)) by an angle of \(\phi_{j_1}\) , link \(l_1\) rotates with it. Assume the system’s origin coordinate frame is located at the basis coordinate frame at \(B_0\). Moreover, the vector \(p_0^w := (x, y, z, a^x, \beta^y, \phi^z)^T\) describes the link’s pose (position and rotation) at the work frame \(B_w\). The 2D kinematic model of such system and its components are illustrated in left of Figure 1.
Figure 1: Simply kinematic model comprising one revolute joint and one link
Kinematic Model
Now, assuming that we will require to program or simulate some motions, we will inevitably be confronted with at least one of the following problems:
Inverse Kinematic Problem: Which is the angle \(\phi_{j1}\) corresponding to an actual pose \(p_0^{w,act}\)?
Forward Kinematic Problem: Which is the resulting link pose \(p_0^w\) of the actual joint angle \(\phi_{j1}^{act}\)?
These questions are depicted on the right of Figure 1 and represent the fundamental problems of kinematic modeling, denoted as the inverse and forward kinematic problems. To answer any of these questions, we first need to estimate all spatial relationships between all consecutive [1] frames of the system. That means from the base \(B_0\) to the joint \(B_{j1}\) and from the joint \(B_{j1}\) to the work frame \(B_w\). Let the relative spatial relationships[2] between two frames be modeled by the translational components \(x_{\Delta}, y_{\Delta}\), and \(z_{\Delta}\) and its rotational counterparts \(\alpha_{\Delta}^x\), \(\beta_{\Delta}^y\), and \(\phi_{\Delta}^z\). Table 1 shows the geometric relationships for all consecutive frames of the kinematic system of Figure 1.
After having defined the geometrical relationships of our system, the kinematic model that will answer the previous questions can now be described. For example, the forward kinematic module that gives the resulting pose for a commanded joint angle could be modeled using the trigonometric relationships depicted in Figure 2.
Figure 2: Trigonometric relationships of reference system
\(x_0^w\) = \(a_1 \cos (\phi_{j1})\)
\(y_0^w\) = 0
\(z_0^w\) = \(d_0 + a_1 \sin (\phi_{j_1})\)
Although these geometric functions sufficiently model the kinematics of our reference system, it should be noted that describing the kinematic model in such a way is not so straightforward for more complex systems with multiple joints and links. For this reason, other mathematical approaches, e.g., homogenous matrices or quaternions, are generally used for computing multiple-coordinate transformations. The description of these techniques falls outside this blog’s scope. For the rest of the article, knowing which inputs and outputs we can expect from a kinematic model is sufficient. These models can be assumed as black-box components, as depicted in Figure 3.
Figure 3: Forward and inverse kinematic black-box models
Implementation
Now that the core concepts of kinematic modeling have been introduced, a seamless way of describing kinematic chains is introduced.
There exists a handful of specifications and formats that address the modeling of kinematic chains, e.g., Collada, AutomationML, OPC UA Robotics. However, in our experience, a standardized format has not been established within the industry. This represents a broader problem in the robotics domain, where programming languages are primarily vendor-specific, and there are no standards for programming or modeling robots. This is one of the reasons why the Robot Operating System (ROS) was founded in 2010. ROS is a FOSS robotics middleware that includes several libraries (e.g., kinematic modeling, perception, visualization, path planning) for hardware-agnostic programming of robotic systems. This has made ROS the state-of-the-art framework used within robotics research. Because of its popularity and characteristics (e.g., performance, hardware-agnostic, FOSS, modularity, SOA), manufacturers of robots, field devices (e.g., grippers and sensors), and software vendors have begun to offer programming interfaces for ROS.
As part of the development of ROS, the Unified Robot Description Format (URDF) was introduced for modeling kinematic chains. The URDF is an open standard XML schema for describing the geometric relationships between joints and links of a robot. In addition to modeling kinematic chains, the URDF provides the possibility to model the physical properties of joints (e.g., inertia, dynamics, and axis limits) or use CAD files for modeling the volumetric properties of links that can be used for collision testing. Furthermore, since the URDF follows an XML schema, kinematic models can be straightforwardly represented in a readable manner. For example, the following excerpt in Figure 4 describes the kinematic relationships between the joint j1 and the link l1 from Table 1.
Having described the geometric relationships between all links and joints using a URDF file, the kinematic model can be visualized and used to calculate end-effector positions or required joint rotations. ROS integrates a handful of packages that use third-party libraries implementing all these functionalities. The use of these libraries is described in the ROS documentation.
<!--All links of our model.-->
<!--The root frame in ROS is called the base_link and represents the root frame (B_0) in our system. -->
<link name="base_link"/>
<!--The link 1 of our model. -->
<link name="link_1"/>
<!-- The work frame of our model is represented as a link.-->
<link name="work_frame"/>
<!--All joints of our model.-->
<!--The revolute joint 1, which couples the base link (parent link) with the link 1 (child link) is modeled here.
The joint is located at the origin of the child link.-->
<joint name="joint_1" type="revolute">
<parent link="base_link"/>
<child link="link_1"/>
<!-- Selection of rotation axis, in our case around the joint is around the z-axis in positive direction.-->
<axis xyz="0 0 1"/>
<!-- The transformation between the parent and child link is given here.-->
<!-- The translational components (xyz) are given in meters. -->
<!-- The rotation is expressed by the Euler angles (rpy) in radians according to the following
notation (r)oll (x-axis rot), (p)itch (y-axis rot.), and (y)aw (z-axis rot.). -->
<origin xyz="0 0 0.4" rpy="1.57079632679 0.0 0.0"/>
<!-- The model of a movable joint must include further physical properties. -->
<limit effort="100" lower="-0.175" upper="3.1416" velocity="0.5"/>
</joint>
Figure 4: URDF excerpt describing kinematic relationship between joint \(j_1\) and link \(l_1\)
Extended System
Having understood the basics of kinematic modeling and how to use URDFs to implement a kinematic model, nothing stands in the way of describing more complex multi-joint kinematic chains like the one shown in Figure 5.
Figure 5: Extended kinematic model considering a prismatic and a revolute joint.
The corresponding geometry relationships are given in Table 2. In addition, the complete URDF can be found attached.
Figure 6: URDF visualization in ROS using two different joint configurations and following values: \(d_0\) = 300mm, \(a_2\) = 500mm, \(a_3\) = 200mm. The image on the right side also depicts the integration of surface models for modeling the volumetric properties of the links.
Summary and Outlook
Programming robots is a complex and resource-exhaustive task requiring expert knowledge, time, and in most cases, the use of the physical system. These barriers directly affect the software development and commissioning of such systems. A kinematic (mock) model of the robot enables the possibility of programming robots without requiring the physical system while reducing costs. However, modeling robot systems is considered a non-trivial task requiring in a first step that their kinematic model is described. For this reason, this blog introduced first the minimal mathematical fundamentals to understand kinematic modeling. Then, in a further step, we showed how kinematic models could be seamlessly implemented using the standard format URDF.
With the blogs’ insights, the reader should be able to describe kinematic models that can be used as mock-ups for prototyping or development purposes. Having overcome the first obstacle of kinematic modeling, the following steps might include:
offer kinematic models as microservices for development, testing, and commissioning purposes (further reading: Mocks in test environment)
develop more user-friendly programming frameworks based on kinematic simulations using cutting-edge technologies such as VR (virtual reality) or AR (augmented reality).
[1] For this reason, these models are commonly denoted as serial kinematic chains. There also exist parallel kinematic models for representing delta robots. The kinematic modeling of such systems lies outside the scope of this blog.
[2] In the robotic domain, the transformation between two coordinate frames is frequently described using homogenous transformations and a set of four parameters describing the translation and orientation displacement, known as the Denavit-Hartenberg parameters.
Figure 1: Overview of the learning factory in Görlitz
While more and more start-ups, mid-sized companies and large corporations are using digitalisation and networking to expand their business, and are developing entirely new business models, the global demand for standardisation and implementation expertise is growing. For example, real-life technologies have long been evolving from phrases that previously didn’t hold a lot of meaning, like “Big Data”, “Internet of Things (IoT)” and “Industry 4.0”; such technologies are driving digital transformation while helping companies to increase their productivity, optimise their supply chains and, ultimately, increase their gross profit margins. They primarily benefit from reusable services from hyperscalers such as Amazon, Microsoft, Google or IBM, but are themselves often unable to implement tailor-made solutions using their own staff. ZEISS Digital Innovation (ZDI) assists and supports its customers in their digital transformation as both a partner and development service provider.
Cloud solutions have long been clunky – especially in the industrial environment. This was due to widespread scepticism regarding data, IT and system security, as well as development and operating costs. In addition, connecting and upgrading a large number of heterogeneous existing systems required a great deal of imagination. For the most part, these basic questions have now been resolved and cloud providers are using specific IoT services to recruit new customers from the manufacturing industry.
In order to illustrate the typical opportunities and challenges borne by IoT environments in the most realistic way possible, an interdisciplinary ZDI team – consisting of competent experts from the areas of business analysis, software architecture, front-end and back-end development, DevOps engineering, test management and test automation – will use a proven agile process to develop a demonstrator that can be used at a later date to check the feasibility of customer-specific requirements.
A networked production environment is simulated in the demonstrator using a fischertechnik Learning Factory and is controlled using a cloud application developed by us. With its various sensors, kinematics, extraction technology and, in particular, a Siemens S7 control unit, the learning factory contains many of the typical elements that are also used in real industrial systems. Established standards such as OPC UA and MQTT are used to link the devices to an integrated IoT gateway, which in turn supplies the collected data via a standard interface to the cloud services that have been optimised for this purpose. Conversely, the gateway also allows controlled access to the production facilities from outside of the factory infrastructure while taking the strict IT and system security requirements into account.
Figure 2: Gripping arm with blue NFC workpiece
Establishing and securing connectivity for employees across all ZDI locations after commissioning has occurred is on one hand an organisational requirement, and on the other, already a core requirement for any practical IoT solution with profound effects for the overall architecture. In terms of technology, the team will initially focus on cloud services offered by Microsoft (Azure) and Amazon (AWS), contributing extensive experiences from challenging customer projects in the IoT environment. Furthermore, the focus remains on architecture and technology reviews as well as the implementation of the initial monitoring use cases. Using this as a foundation, more complex use cases for cycle time optimisation, machine efficiency, quality assurance or tracing (track and trace) are in the planning phase.
ZDI is also especially well positioned in the testing services field. Unlike in extremely software-heavy industries such as logistics or the financial sector, however, test managers for numerous production-related use cases were repeatedly confronted with the question of how hardware, software and, in particular, their interaction at the control level can be tested in full and automatically, without requiring valuable machine and system time. In hyper-complex production environments, such as those that ZEISS has come across in the semiconductor and automotive industries, digital twins, which are widely used otherwise, only provide a limited degree of mitigation as relationships are difficult to model and, occasionally, fully unknown influencing factors are involved. This makes it all the more important to design a suitable testing environment that can be used to narrow down errors, reproduce them and eliminate them in the most minimally invasive way possible.
We will use this blog to regularly report on the project’s progress and share our experiences.
