Virtual Factory Operating Systems (vf-OS) Architecture – What do you need to know?
The World is facing the fourth industrial revolution based on ICT, specifically architectures and services, as key innovation drivers for manufacturing companies. Traditional factories will increasingly be transformed into smart digital manufacturing environments but currently the full potential for ICT in manufacturing is far from being fully exploited. Factories are complex systems of systems and there is a need to develop a platform on which future manufacturing applications can be built. To achieve this goal, it is necessary to build such a system on a foundation: The vf-OS Architecture.
The main focus of the entire specification process for the vf-OS environment entails the interaction of the different and a security concept. a security concept was modelled, to which all components in the architecture will adhere in order to guarantee the highest degree of security and confidentiality.
At the beginning, an architecture was created under the TOGAFs guideline. A high-level architecture can be seen in Figure 1. Among other things, Architectural Building Blocks (ABB) and Solution Building Blocks (SBB) were defined, which helped the consortium to make correct decisions regarding communication channels and component responsibilities. vf-OS is using a Service Oriented Architecture (SOA) approach in which the different vf-OS components implement individual functionalities and thus the composition of all these inter-related components form the complete vf-OS architecture to ground the vf-OS ecosystem. The resulting ABBS are:
Environment Block: The vf-OS Platform acts as an executing environment of vf-OS architecture. It acts as a container, which includes all other components.
Application Development Block aka design time comprises the different vf-OS components that will be used for the development of vf-OS Manufacturing Assets/vApps.
Application Services & Middleware Block aka Runtime includes the vf-OS components that will be used by the Assets/vApps, when they are requesting vf-OS resources.
Application-Deployment Block includes all vf-OS components that will be taken into consideration when the vf-OS environment is going to be in use.
The SBBs derived from this are: FIWARE Enablers; Specific Enablers; Open Source Solutions; Existing Solutions; New Development. ABBs and SBBs ultimately form the basis for further specification.
These include the functional specification on the one hand and the technical specification on the other. In the functional specification, functionalities of individual components and their feasibility were analyzed on the basis of user requirements. Therefore, Story Maps are defined, which organize user stories for software development in a matrix, following the user workflow from left to right and the user priority from top to bottom. User stories capture the functionality that needs to be developed with enough granularity to identify inconsistencies or overlapping of functionalities between components. The story maps are linked to UML sequence diagrams used to depict the interactions between components and to UI mock-ups that describe the interaction with users. This way, every activity in the story map sequence has a high-level description of the interaction with external components and/or users.
The technical specification, however, describes the intersections of the vf-OS components for developers. As already described, vf-OS follows the SoA approach. Therefore, the REST standard was agreed to allow the components to communicate with each other. The technical specifications of the RESTful interfaces consist of the 3 main points description, request, and response. These were documented in the online tool Slate and are available for all developers during the development phase. Changes can be made at any time, so that the most status can always be found there.
The vf-OS specification is rounded off with the safety concept. It describes measures to protect vf-OS from cyber-attacks (e.g. denial of service, ransomware, espionage). Hence, guaranteeing continuous and appropriate availability, integrity and confidentiality (AIC) levels along the whole vf-OS infrastructure calls for a solid, holistic security and privacy model. This model elicits know-how from reference software development life cycles, applicable regulations (General Data Protection Regulations), key industrial IT standards (mainly ISA-62443) and recommendations from top-class security institutions (e.g. NSA, NIST). The objectives pursued are to minimize attack surfaces, maintain security risks at acceptable levels and keep security threats at bay, while minimizing the negative impact of security measures on the functionality and performance of vf-OS services.
After completion of the specification phase, the remaining RTD work can begin to implement the components.
For more information please visit the vf-OS Website.