cps tools - requirements analysis

Funded by the European Union’s H2020 GA - 826276

CPS Tools - Requirement Analysis

Deliverable ID: Version:

D5.1 (D69) Rev1.1, 15 July 2020

Due Date: 29 February 2020

WP5 – CPS tools

CPS4EU – Cyber Physical Systems for Europe WP 5 - Tools Background and Requirement Analysis

Deliverable ID: D5.1 (D69) Rev1.1, 15 July 2020 Page 1

CPS4EU WP 5 – D5.1 (D69) CPS Tools - Requirements Analysis

Document Manager: Réda NOUACER

Project Title: Cyber Physical Systems for Europe

Project Acronym: CPS4EU

Contract Number: 826276

Project Coordinator: VALEO

WP Leader: CEA

Task: T5.1 T5.2 T5.3 Task Leader: CEA, ANSYS, INRIA

Document ID: D5.1 (D69) Version: Rev1.1

Deliverable Title: CPS Tools - Requirement Analysis Date: 15 July 2020

Approved:

Document Classification: Public

Approval Status

Prepared by: Morayo ADEDJOUMA

Approved by (WP Leader): Réda NOUACER

Approved by (Coordinator): Philippe GOUGEON

Approved by (Technical PM) Antoine DUPRET



Keywords:

Abstract

DISCLAIMER

This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content. This document may contain material, which is the copyright of certain CPS4EU consortium parties, and may not be reproduced or copied without permission. All CPS4EU consortium parties have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information.

Neither the CPS4EU consortium as a whole, nor a certain party of the CPS4EU consortium warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, and does not accept any liability for loss or damage suffered by any person using this information.

ACKNOWLEDGEMENT

This document is a deliverable of CPS4EU project. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 826276.



Contributors

Name Partner

Réda Nouacer, Morayo Adedjouma, Yves Lhuillier, Zakaria Chihani CEA

Michel Rochette, Valery Morgenthaler, Xavier Fornari ANSYS

Ylies Falcone INRIA

Sahar GUERMAZI, Philippe Fiani SHERPA-Engineering

Paolo Azzoni EUROTECH

Oliver Oey, Timo Stripf EMX

Sven Hartmann TUC

Carina Mieth, Markus Scholz, Jens Ottnad TRUMPF

Bernhard Bauer UnA

Ester Palacios, Sergio Saez, Daniel SÁEZ-DOMINGO ITI

Rebella Nicolo, Donatella Ansaldo, Di Marco Giovanni, Graffione Ilaria LEONARDO

Antoine El-Hokayem, Saddek Bensalem, Yassine Lakhnech UGA

Version History

Version# Date Reason for change Released by

- 12.11.2019 Template First Release R. Nouacer M. Adedjouma

09.04.2019 Integration of partners background and use-cases requirements analysis

R. Nouacer M. Adedjouma M. Rochette O. Oye Y. Falcone

06.05.2020 Integration of internal review feedback R. Nouacer M. Adedjouma

15.07.2020 Integration of project coordinator review feedback R. Nouacer L. Palacios M. Adedjouma

Distribution List

Name Company/Organization Role / Title

Consortium CPS4EU Consortium n/a



TABLE OF CONTENTS

Executive Summary ............................................................................................................................... 8

0 Introduction .................................................................................................................................... 9

0.1 Purpose ......................................................................................................................... 9

0.2 Scope ............................................................................................................................. 9

0.3 Link to other documents/TASKS ..................................................................................... 9

0.4 Definitions, acronyms, and abbreviations ....................................................................... 9

1 Future challenges of CPS ................................................................................................................ 10

1.1 CPS Requirements analysis ........................................................................................... 10

1.2 CPS4EU Needs .............................................................................................................. 11

1.2.1 Artificial Intelligence design and validation .......................................................................................... 11

1.2.2 Modelling, Simulation and virtualization of CPS (Digital Twins) ........................................................... 11

1.2.3 Safety, Security, Privacy ........................................................................................................................ 12

2 Tools to support CPS needs ........................................................................................................... 13

2.1 Overview of tool needs ................................................................................................ 13

2.2 USE CASE tools needs ................................................................................................... 13

2.2.1 WP7 tool needs ..................................................................................................................................... 13

2.2.2 WP8 tool needs .................................................................................................................................... 13

2.2.3 WP9 tool needs ..................................................................................................................................... 14

2.2.4 Summary of use-cases tool needs ......................................................................................................... 15

3 CPS4EU tooling framework ............................................................................................................ 18

3.1 Framework description ................................................................................................ 18

3.1.1 Requirements Elicitation & Specification Definition ............................................................................. 18

3.1.2 Functional Design .................................................................................................................................. 18

3.1.3 Procurement & Engineering .................................................................................................................. 19

3.1.4 Deployment & Commissioning.............................................................................................................. 20

3.1.5 Operation & Management .................................................................................................................... 20

3.1.6 Maintenance, Retirement & Recycling ................................................................................................. 21

3.1.7 Evolution ............................................................................................................................................... 21

3.1.8 Training & Education ............................................................................................................................. 21

3.2 ANSYS .......................................................................................................................... 22

3.2.1 Background ........................................................................................................................................... 22

3.2.2 Towards qualification ............................................................................................................................ 24

3.2.3 Contribution .......................................................................................................................................... 24

3.3 CEA .............................................................................................................................. 25

3.3.1 Background ........................................................................................................................................... 25



3.3.2 Contribution .......................................................................................................................................... 30


3.4 INRIA ........................................................................................................................... 40

3.4.1 Background ........................................................................................................................................... 40


3.4.3 Contribution .......................................................................................................................................... 41

3.5 SHERPA-Engineering ..................................................................................................... 42

3.5.1 Background ........................................................................................................................................... 42


3.5.3 Contribution .......................................................................................................................................... 45

3.6 UGA ............................................................................................................................. 46

3.6.1 Background ........................................................................................................................................... 46


3.6.3 Contribution .......................................................................................................................................... 50

3.7 EUROTECH ................................................................................................................... 50

3.7.1 Background ........................................................................................................................................... 50


3.7.3 Contribution .......................................................................................................................................... 53

3.8 EMX ............................................................................................................................. 54

3.8.1 Background ........................................................................................................................................... 54


3.8.3 Contribution .......................................................................................................................................... 56

3.9 TUC .............................................................................................................................. 57

3.9.1 Background ........................................................................................................................................... 57


3.9.3 Contribution .......................................................................................................................................... 59

3.10 TRUMPF ....................................................................................................................... 61

3.10.1 Background ........................................................................................................................................... 61


3.10.3 Contribution .......................................................................................................................................... 62

3.11 UnA ............................................................................................................................. 63

3.11.1 Background ........................................................................................................................................... 63


3.11.3 Contribution .......................................................................................................................................... 68

3.12 ITI ................................................................................................................................ 70

3.12.1 Background ........................................................................................................................................... 70


3.12.3 Contribution .......................................................................................................................................... 73

4 Conclusion .................................................................................................................................... 74



References........................................................................................................................................... 75



TABLES

No illustration table entry was found.

FIGURES

Figure 1 - Generic Architecture of Cyber-Physical System (CPS) ...................................................................................... 10 Figure 2 - Fault-injection and impact analysis ................................................................................................................. 27 Figure 3 - Papyrus features for compliance management of CPS Systems. ..................................................................... 29 Figure 4 - Phi-Suite, a Model-Based Methodology for System Design & Evaluation ....................................................... 42 Figure 5 - An Internal Block Diagram for architecture definition ..................................................................................... 43 Figure 6 - Simulation architecture extracted from the system model ............................................................................. 43 Figure 7 - A block diagram for digital simulation ............................................................................................................. 44 Figure 8 - Post-processing and system analysis tooling ................................................................................................... 44 Figure 9 - A generic platform and its instantiation on market segments: automotive and smart grid ............................ 45 Figure 10 - An example of data flow programming ......................................................................................................... 51 Figure 11 - Kapua web console ........................................................................................................................................ 52 Figure 12 - Overview of emmtrix workflow ..................................................................................................................... 54 Figure 13 - Overview of GUI of emmtrix Parallel Studio .................................................................................................. 55 Figure 14 - Open Scenario Infrastructure ......................................................................................................................... 57 Figure 15 - Scenario development approach ................................................................................................................... 58 Figure 16 - Workflow ........................................................................................................................................................ 58 Figure 17 - Simulation Scenario Development ................................................................................................................. 60 Figure 18 - Smart Factory Simulation Framework ............................................................................................................ 61 Figure 19 - ITI: areas of work in CPS group....................................................................................................................... 71 Figure 20 - Art2kitekt Framework working for the aircraft domain. ................................................................................ 72 Figure 21 - Tasks to be developed within Art2kitekt Framework .................................................................................... 72 Figure 22 - Module diagram of the software tool. ........................................................................................................... 72



EXECUTIVE SUMMARY

Cyber-Physical Systems (CPS) are a new generation of systems combining intensive connectivity, embedded computing and local intelligence, to create a link between the physical and digital worlds and allow cooperation between systems. Different enabling technologies are at the centre of the development of innovative CPS like autonomy, artificial intelligence, computing, connectivity, cooperative features, etc. The design of CPS presents many challenges because of their complexity, strong safety requirements, distribution, and real-time nature.

This deliverable, based on the needs of the CPS and the analysis of the tool needs related to the use cases, maps the tools of the CPS4EU participants and identifies relevant improvements to address the challenges posed by the integration of emerging technologies in these systems.



0 INTRODUCTION

0.1 PURPOSE

This deliverable D5.1 (CPS Tools - Requirements Analysis) aims to study the needs of the case studies in terms of tools in order to identify possible correlations between the skills of the partners participating in WP5 and these needs.

0.2 SCOPE

This document covers tasks:

T5.1: AI integration in CPS

T5.2: Simulation for CPS

T5.3: Trustworthy system engineering

0.3 LINK TO OTHER DOCUMENTS/TASKS

ID Description

WP7 CPS Automotive

WP8 CPS Industry automation

WP9 CPS for other industrial sectors

0.4 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

Definition / acronym / abbreviation Description

CPS Cyber-Physical System

AI Artificial Intelligence

DL Deep Learning

NN Neural Network

DT Digital Twin



1 FUTURE CHALLENGES OF CPS

1.1 CPS REQUIREMENTS ANALYSIS

Cyber-Physical Systems (CPS) are a new generation of systems combining intensive connectivity, embedded computing and local intelligence, to create a link between the physical and digital worlds and allow cooperation between systems. As depicted in Figure 1, a CPS has the capability to interact with an evolving environment. It owns a set of sensors and actuators through which it interacts with its environment. Its computation is a set of computing nodes that may loop and store data before taking decisions to interact with the environment. A CPS may itself be a system of CPS. To connect the sensing, the actuating and computing parts of a (system of) CPS, there are internal or external connectors (e.g. networks, hardwire, etc.). Last but not least, as the environment evolves, real-time and performance properties are key features to take into account for CPS.

Figure 1 - Generic Architecture of Cyber-Physical System (CPS)

Leveraging on key basic technologies enabling digitalisation, e.g. nanoelectronics, sensors, AI, cybersecurity, CPS represent key drivers of the innovation capacity of European industries, generating sustainable economic growth and supporting meaningful jobs for citizens. Thanks to them, important sectors such as automotive, energy and industrial automation have already made remarkable progress that has enabled them to provide innovative systems. However, the importance of CPS increases with massive digitalization, bringing new challenges to maintain, strengthen and extend the strong European position in these enabling technologies, as highlighted in the paragraphs below:

• Connectivity: While the majority of digital systems were traditionally developed to operate independently of each other, future generation products will be fundamentally modified by the intensive connectivity of systems leading to systems of systems. This means combining two types of links: on one hand, the connectivity of objects within a system with strong constraints on safety and on the other hand, the connectivity of the system with the outside world with strong security constraints. The goal with respect to this intensive connectivity is



to guarantee dynamic management of applicative flows and continuity of service in order to ensure the control, localization of CPS devices, distribution and collection of contents and critical & non-critical data.

• Computing: CPS are equipped with embedded local intelligence to meet the inherent requirements in terms of

quality of service and new applications. Their large diversity implies different types of computing needs: on one hand, to provide a need of computing method that is deterministic and a high performance combined with low power; on the other hand, to ensure the effective processing of AI and deep learning algorithms;

• Cooperative system: The interaction of the computing layer with the physical world (sensors, actuators), initiated by the concept of embedded systems evolve towards autonomous systems that need to interact with dynamic and evolving environment. The point is to establish cooperation between human/mobile and system/infrastructure, to make information reliable and context-aware, and to improve performances through cooperation and auto-adaptation of the system.

• Trustworthiness: As CPS are often connected critical systems, they also brings new challenges concerning safety, security, access to data, protection of personal data, which have also to be addressed.

1.2 CPS4EU NEEDS

Different enabling technologies are at the centre of the development of innovative CPS like autonomy, artificial intelligence, computing, connectivity, cooperative features, etc. The aim of the CPS4EU project is to define and implement pre-integrated architectures as a multi-purpose HW-SW system to serve these different enabling technologies. To build these architectures, the enabling technologies must be boosted and integrate into a supply chain to design, validate, produce and qualify the future CPS. A success criterion to achieve the goal relies on defining full set of design and validation tools aimed to increase efficiency and productivity. These tools should include design and validation of AI components, modelling and simulation of the control of CPS, from components to large systems, applications virtualization of specific pre-architecture, tools, methods and processes dedicated to ensure dependability and performance properties of such pre-architectures.

1.2.1 Artificial Intelligence design and validation

Automated and autonomously acting CPS are seen as one of the major technological advancements that will shape the quality of our future life. There will be increasing demand of autonomy for those systems to deal with increasing complex decision-making in increasing complex situations. To cope with this challenge, the CPS will have to embed more and more smartness & intelligence in all their development aspects - including control algorithm, sensing and actuating, performance and reliability, energy utilization, etc. - taking advantage of new concepts as artificial intelligence (AI) with deep learning (DL) and reinforcement learning techniques based on neural networks (NN).

But AI techniques presents some shortcomings to address before integrating them in CPS and letting them safely interact with humans. AI components are data-based and data-driven algorithms used to capture, interpret, reason and act in interaction with people and environment. The algorithms perform as good as the data used to defined them (e.g trained and tested). A problem is that these data can be tainted with several quality and quantity issues that may undermine the performance of the algorithms: bias, uncertainty, labelling errors, validity, availability, improper source, etc. Another challenge relies on the implementation of the AI models that required high computing capacity and new ways to interface with tools, data storage and infrastructure that existing frameworks do not provide. An additional challenge poses by AI integration in CPS is the testing and validation of such software. Currently, there is no ground truth mean to ensure that the behaviour they exhibit is the appropriate one in the sense they lack for interpretability and explainability as black-box models. These challenges require scientific breakthroughs in tools, methods and processes to allow a wide adoption of AI technology in industry, with known levels of trust.

1.2.2 Modelling, Simulation and virtualization of CPS (Digital Twins)

Modelling, simulation and virtualization offers versatile opportunities to cope with the complexity of CPS. Modelling the systems as a digital twin enable to deal with the increasing technology embedded in these systems. With this



virtual copy, it is possible to test, refine and optimize architectures, i.e. mechanical, electrical and control designs, and the integration between them, at lower cost well before their effective implementation.

Simulation is a key enabler to perform early testing and a realistic validation of a system with all its components and all behavioural aspects, allowing for identification and resolution of errors, as well as optimization of control strategy in the system. Besides virtual assembly and early testing of CPS, modelling and simulation serve others digitalisation challenges, such as study alternative designs, optimizing solutions, ascertaining safety, providing predictive maintenance capabilities, offering versatile environment for operator training or a test-bench for automation. Simulators may also be used online and parallel with its real counterpart to predict future behaviour and performance, to give early warnings, to outline alternative scenarios for decision-making, etc.

However, heterogeneous systems are an issue for digital twin. Different platforms exist to support the diverse engineering disciplines, but there is no interoperability yet between them. The challenge to address is to allow having all relevant engineering disciplines (processes, assembly, electronics and electrical, information systems, etc.) modelled and properly simulated together on a same platform or between connected and interoperable platforms.

1.2.3 Safety, Security, Privacy

As the proportion of electronics and software increases more and more in CPS, so does the demand for safe, secure, reliable and non-hackable operation of these systems. In addition, privacy protection is essential for systems and their pilots/operators. These requirements ask for fail-safe operational technologies that deliver intrinsically safe operation and fail-safe fall-back from component to subsystem and provides a fall-back for problems in interaction with the environment. Due to the large-scale connectivity solutions used by CPS, security is also a crucial issue that needs to be resolved prior to deploying such systems. This requires new research, development and innovation to build the tools, methods and processes necessary for the development and validation of the new CPS, both in the development phase and in the operational phase. In this context, standardization will be of the utmost importance to achieve wide public acceptance, including the integration of improved security, safety and confidentiality features of CPS.



2 TOOLS TO SUPPORT CPS NEEDS

2.1 OVERVIEW OF TOOL NEEDS

Cyber Physical Systems are a new generation of systems combining intensive connectivity, embedded computing and local intelligence, to create a link between physical and digital worlds and enable cooperation among systems. WP5 will focus on developing tool chains and associated design flows with the aim to support EU industries to easily adopt and integrate CPS technologies and so supporting their digitalization programs. More specifically, we consider three types of tools:

• Supporting design, implementation, deployment, system integration and validation of Artificial Intelligence components in CPS. It covers engineering of embedded intelligence to provide support to the development of advanced, decision systems based on learning, perception systems, particularly vision, and dynamic optimization systems of control and resources.

• Intensive use of simulation in CPS domain, including global system simulation of complex cyber physical systems and simulation embedded in CPS to enrich their functionalities. It covers capabilities to embed efficient real time simulation function in the CPS, and to provide simulation early in the development workflow of complex CPS managing multi-physics and multi-formalisms used in system modelling and simulation.

• Validation of CPS related to their various constraints: safety, security, communication and interoperability. It covers engineering for trusted systems; the issue is the implementation of new process of qualification, analysis, audit, both in development (design - validation) and in operating phase that may take into account efficiently and reliably the different parts of the CPS. It concerns as well development and integration of CPS tools for the pre-integrated architectures developed within the project to ensure the applicability in European industrial products.

The key idea is to consolidate requirement specifications of common CPS components from a variety of uses cases. This approach will separate the engineering work needed to integrate multiple CPS modules from the application design. The strengthening of European CPS procurement chain will be made possible by a close cooperation between CPS technology providers and CPS users, for the specifications and validation of future CPS technology components. The tools developed in WP5 will also receive inputs on requirements in this regard from technology and application use case WPs.

2.2 USE CASE TOOLS NEEDS

2.2.1 WP7 tool needs

WP Owner Name Potential tool needs

WP7 Valeo & Sysnav

Safe and enhanced positioning with inertial navigation unit

Architecture modelling

Reliability analysis

Simulation tools for sensor systems

Safety analysis

Security analyses

Evaluation tests

WP7 TRT Secure connectivity subsystem Verification of connectivity

Security analysis





WP8 TRUMPF Material flow analytics and simulation Simulation tools

Real-time controlling

WP8

WIKA

Collaborative Lifting (a.k.a. Mobile CPS)

AI-powered algorithms.

Supervision & execution: “Possibility of autonomous execution of the lifting process”.

Modelling tools

Simulation tools

Algorithm development

Augmented reality

WP8 Leonardo Automatic Vacuum System

Software development (SDK, IDE, compiler, debugger, modeling & simulation, …)

Edge computing

Monitoring tools (e.g. digitalization infrastructure monitoring)

Remote management tools (e.g. software updates)

Data analysis (e.g. predictive maintenance, image analysis, etc.)

WP8 Leonardo Trimming Quality Improvement


Edge computing



Data analysis (e.g. AI/ML modelling tools for trimming data analysis, quality statistics, etc.)

WP8 Leonardo Thermoplastic production line monitoring


Edge computing



Data analysis (e.g. AI/ML modelling tools for thermoplastic process data analysis, quality statistics, image analysis, etc.)

WP8 Leonardo Aircrafts health management system

Software development (IDE, compiler, debugger, modeling & simulation, …)

Data analysis (e.g. AI/ML for predictive maintenance, trend monitoring, etc.)



WP9 RTE Distributed controls for transmission network

Architecture (distributed, IoT) modelling,

Resource optimization

Monitoring and diagnostic tools


Security and safety analysis



fault injection to check robustness against safety & reliability properties

real time monitoring & diagnosis tool

security analysis

Open source code

Secured OS

System (requirements + structure) modelling

Link between the UC functional requirements and the architectures

Evaluation and performance analysis of architectures

Design and evaluation of control strategies

Architecture (components and subsystems) dimensioning

Data monitoring

WP9 Schneider Safety report for critical function -

Substation virtualization

safety analysis

architecture modelling,

testing (HiL, unit, integration)

WP9 BME

CPS based flow chemistry modules with predictive maintenance technologies for Pharma 4.0

Use case specification not finished

WP9 Airlane Intelligent motor control application as SaaS to offer machine learning capabilities for external parties

Edge computing

Online AI model development (python , javascript-based) and training in cloud

Data collection

data connectivity with low power consumption

AI models

Edge Computing

Data gathering

Machine Learning

WP9 Arcure

Pedestrian detection on off-Road Construction trucks based in the Artificial intelligence with the Vision technology

Deep Learning algorithm for pedestrian detection

Safety/reliability analysis

Real time monitoring

WP9 ACOEM Monitoring network for Environment Quality (well-being) and Threat Detection in one big European city

Data collection and analysis

GDPR

Geolocalisation

AI algorithm (classification, measurement correction)

Sensor development (pod) [with low energy, long range communication, light, accurate, and cost effective]

IA threat detection system based on acoustic method

Real time Monitoring

WP9 M3S Open Loop testbench allowing the validation of the developed sensor for Automated Driving applications

Use case specification not finished

2.2.4 Summary of use-cases tool needs

CPS4EU use-cases needs Subsystems / Features WP



Architecture modelling / Modelling Tools


WP7 (Valeo, Sysnav)

Collaborative Lifting (a.k.a. Mobile CPS) WP8 (WIKA)

Distributed controls for transmission network WP9 (RTE)

Safety report for critical function - Substation virtualization

WP9 (Schneider)



WP7 (Valeo, Sysnav)



WP9 (Arcure)

Simulation tools / Fault injection


WP7 (Valeo, Sysnav)

Material flow analytics and simulation WP8 (TRUMPF)


Monitoring network for Environment Quality (well-being) and Threat Detection in one big European city

WP9 (ACOEM)

Security & Safety analysis


WP7 (Valeo, Sysnav)

Secure connectivity subsystem WP7 (TRT)



WP9 (Schneider)


WP9 (Arcure)

Evaluation tests / Testing


WP7 (Valeo, Sysnav)


WP9 (Schneider)

Verification of connectivity Secure connectivity subsystem WP7 (TRT)

Real-time controlling / Monitoring & Diagnosis tools

Material flow analytics and simulation WP8 (TRUMPF)

Automatic Vacuum System WP8 (Leonardo)

Trimming Quality Improvement WP8 (Leonardo)

Thermoplastic production line monitoring WP8 (Leonardo)



WP9 (Arcure)

AI-powered algorithms / Algorithm development



WP9 (ACOEM)

Intelligent motor control application as SaaS to offer machine learning capabilities for external parties

WP9 (Airlane)


WP9 (Arcure)

Supervision & execution: “Possibility of autonomous execution of the lifting process”


Augmented reality Collaborative Lifting (a.k.a. Mobile CPS) WP8 (WIKA)







Aircrafts health management system WP8 (Leonardo)

Edge computing





WP9 (Airlane)





Data analysis & Collection (e.g. AI/ML modelling tools for trimming data analysis, quality statistics, etc.)




Aircrafts health management system WP8 (Leonardo)


WP9 (Airlane)


WP9 (ACOEM)

Sensor development / Data connectivity with low power consumption


WP9 (Airlane)


WP9 (ACOEM)

GDPR Monitoring network for Environment Quality (well-being) and Threat Detection in one big European city

WP9 (ACOEM)

Geolocalisation Monitoring network for Environment Quality (well-being) and Threat Detection in one big European city

WP9 (ACOEM)

Open source code

Secured OS

Link between the UC functional requirements and the architectures

Evaluation and performance analysis of architectures

Design and evaluation of control strategies




3 CPS4EU TOOLING FRAMEWORK

3.1 FRAMEWORK DESCRIPTION

The framework consists of several different tools from multiple partners that cover different parts of the development cycle for CPS. The categorization into eight separate steps follows the engineering phases as defined by the ArrowHead-Tools1 project and as employed commonly for the development of CPSs.

3.1.1 Requirements Elicitation & Specification Definition

Definition: Requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The output of this phase is typically a list of requirements.

Partner contributions:

- CEA o Papyrus Requirement o Maat Requirement Efficiency ( + AI augmented conformity based on NLP based) o Papyrus Sequoia - Product line o AI augmented design

- ITI o art2kitekt traceability - Management tool for tracking requirements easily

- UnA o EMF Meta Model Requirement

3.1.2 Functional Design

Definition: The functional design phase consists in adopting the "functional design" paradigm to simplify the design of the system/product. A functional design assures that each modular part of the system/product has only one responsibility and performs that responsibility with the minimum of side effects on other parts. Functionally designed modules tend to have low coupling. The output of this phase is typically a model, or an architecture.


- Ansys o Ansys medini – safety and security analysis o Ansys SCADE – Architect analysis o Ansys physics - fluids, electro-magnetism, structures, semi-conductors, optical, sound

- CEA o Papyrus Modeler + AI component design o Sophia - Safety analysis o ARES - Security analysis o Maat - Design validation o Papyrus Moka - model simulation o NN visualization & checking tool

- ETH o Kura WIRES - define a data flow graph to process data on the edge of an IoT infrastructure

- INRIA o THEMIS Framework – design of decentralized monitoring algorithms

- ITI o art2kitekt framework - for functional simulation of CPS components and real-time behaviour of

1 https://www.arrowhead.eu/arrowheadtools



underlying platform used for verification of CPS - SHERPA

o PhiSystem – tool for design of CPS - TUC

o a simulation scenario definition language to unify the usage of scenarios - UnA

o Sirius Modeler o EID - Safety & security analysis o Sirius Service Interoperability Analysis o FIA - Impact and dependency analysis o Sirius QIA - Assessment method o Sirius Design validation analysis o PRF - Sirius safety and security validation

3.1.3 Procurement & Engineering

Definition: The procurement is the process of finding and agreeing to terms, and acquiring goods, services, or works from an external source required to engineer the system/product and construct/manufacture it. Procurement is used to ensure the buyer receives goods, services, or works at the best possible price when aspects such as quality, quantity, time, and location are compared.

The engineering phase includes the design, development and test of the system/product, generating a prototype of the system/product and, after some iterations the final version of system/product (that will be deployed and commissioned).


- Ansys o Ansys ROM o Ansys SCADE tool chain: Suite (Control), Display(HMI) Test (Test), LifeCycle (ALM) o Ansys TwinBuilder o Ansys VRX Simulator

- CEA o Maat Design Validation - model symbolic validation o Unisim - dynamic code analysis + DNN analyzer o Frama-C - static code analysis o Papyrus Designer - code generation o Artimon - runtime testing o Maât System Compliance - offline testing o Maât Test execution

- EMX o Code Generator – C code generation from MATLAB®/Simulink o Parallel Studio – Generation of parallel C code for embedded target platforms

- ETH o Abstraction Layer SOA Services - simplify the development of a business application on the edge of

an IoT infrastructure o Device Virtual Twin - simulate a device deployed on the edge of an IoT infrastructure

- INRIA o THEMIS Framework – development of decentralized monitoring algorithms

- ITI o art2kitekt code generation - generate code from model designs to optimize their execution and

improve their maintainability - SHERPA



o PhiSim – evaluation of CPS - TRUMPF

o a smart factory simulation framework for the evaluation of logistical targets - UnA

o AST - Static Application Security Testing o TSA - Trust-based Security Analysis o TIA - Trust-based Impact Analysis o PRF - Pattern Recognition for flaw identification (model validation) o Code generation for Pattern Recognition o CPS-EID - architectural decision support

3.1.4 Deployment & Commissioning

Definition: The deployment phase consists in the installation/integration of the system/product in the final operative environment. The deployment includes also the preliminary verification and validation of the system/product, that precede the commissioning.

The commissioning phase is the process of assuring that the system/product is designed, installed, tested, operated, and maintained according to the operational requirements of the owner or final client. A commissioning process may be applied not only to new projects but also to existing units and systems subject to expansion, renovation or revamping.


- Ansys o SCADE qualified tools (DO-178C, EN 50128, IEC 61508, ISO 26262, IEC 68 880)

- CEA o Papyrus qualification support (wrt standards) + evolving qualification

- ETH o Kapua Web Console - manage the deployment of a fleet of devices in an IoT installation o Kura Provisioning Service - manage provisioning on the edge of a fleet of devices in an IoT

installation - UnA

o Sirius modelling support before deployment

3.1.5 Operation & Management

Definition: This phase consists of operating and managing the system/product according to the operational specification of the system/product and requirements of the owner or final client.


- Ansys o Ansys TwinBuilder

- CEA o AI components runtime management o Papyrus qualification support (wrt standards) + evolving qualification

- ETH o Kapua Web Console - remotely manage a fleet of devices in an IoT installation during operations

- SHERPA o PhiSuite – validation of CPS

- UnA o CPS-EID - Architectural change decision support



3.1.6 Maintenance, Retirement & Recycling

Definition: Maintenance consists in identifying and establish requirements and tasks to be accomplished for achieving, restoring, and maintaining operational capability for the life of the system/product. For a system/product to be sustained throughout its system life cycle, the maintenance process has to be executed concurrently with the operations process. Maintenance addresses bug fixes and minor enhancements, as well as, minor adaptations to standard, new features, etc... Significant changes in the system/product are considered in the evolution phase. In the maintenance phase we can also consider the de-commissioning of the system/product at its end-of-life.


- Ansys o Ansys Twinbuilder o SCADE Test

- CEA o Maât System Compliance - offline symbolic testing o Artimon - monitoring o Maat Test execution

- ETH o Kapua Web Console - remotely manage the maintenance (e.g. FW updates, faults, etc.) and

retirement of a fleet of devices in an IoT installation - INRIA

o THEMIS Framework – analysis of decentralized monitoring algorithms

3.1.7 Evolution

Definition: The evolution phase deals with the inability to predict how user requirements, market and technology trends will evolve a priori. The role of this phase is to monitor these aspects and identify potential significant changes in the future version of the system/products. The evolution phase must ensure also a continuous improvement of the system/product, always respecting the user requirements in an efficient, reliable and flexible way. Finally, this phase has to deal with the management of the end-of-life of the system/product.


- Ansys o Ansys physics: Fluids, Electro-magnetism, Structures, Semi-con. Optical, Sound o Ansys ROM o Ansys SCADE tool chain: Suite (Control), Display(HMI) Test (Test), LifeCycle (ALM) o Ansys TwinBuilder o Ansys VRX Simulator

- CEA o Papyrus qualification support (wrt standards) o Papyrus Sequoia - Product line o Maât System Compliance - offline symbolic testing o Artimon - non regression testing o Maat Test execution

3.1.8 Training & Education

Definition: This phase includes all the educational and professional training activities required by the engineering process, across the entire system/product lifecycle.


- Ansys



o Ansys online documentation and Learning Hub - CEA

o Papyrus online2 and tool integrated documentation - UnA

o EMF Documentation o Sirius Documentation o UnA Tool Documentation

3.2 ANSYS

3.2.1 Background

3.2.1.1 Overview

ANSYS France SAS is a subsidiary of American company ANSYS Inc, the worldwide leader in engineering simulation market. ANSYS is the leading engineering simulation software developer based in 40 countries across the world employing more than 3,500 employees. Created in 1970, we are exclusively focusing on the development of engineering simulation software covering all necessary physics such as fluid, structure, electromagnetic and acoustic. We complete our portfolio by providing full system and software modelling capabilities. ANSYS France SAS, with more than 300 employees, mainly provides technical support in simulation and also include a development team of 140 engineers. This development team leads ANSYS research in multi body dynamics, cloud computing, embedded software, response surface, optimization, probabilistic and reduced order modelling techniques.

In CPS4EU ANSYS will develop the three key tools for simulation including an adaptation of the execution support to the CPS target platforms selected by the partners:

- 3D real time Simulation powered by Deep Learning (ROM Builder), covering multi-physics simulation (Fluids, Mechanical, Thermal, Coupled Physics…).

- Runtime Digital Twin: Industrialization of a hybrid release of SCADE, and prototyping of execution support of Digital Twin.

- Digital Twin Creation (Twin Builder): creation of real-time simulation applications from 3D simulations, system simulation offering a wide variety of models including FMU. Automated construction of real-time applications.

3.2.1.2 Main Features

ANSYS will develop the following features:

Dynamic ROM Builder

Dynamic ROM Builder is a module of ANSYS Twin Builder which is the solution for system simulation and twin creation. The main goal of Dynamic ROM Builder is the learning and validation of a reduced order model from transient and nonlinear 3D simulation data. The approach is very general:

- For any type of 3D physics solver including coupled fields, - For any type of inputs. Inputs are excitations varying time and scalar parameters which vary from one

scenario to another one but do not vary in time. - For any type of outputs. Outputs could be scalar results varying in time and fields varying in time. - Graphic display of field’s results.

2 Eclipse Papyrus youtube Channel: https://www.youtube.com/channel/UCxyPoBlZc_rKLS7_K2dtwYA

https://www.youtube.com/channel/UCxyPoBlZc_rKLS7_K2dtwYA



The ROM could be exported into Twin Builder using FMU format. In addition to core developments using artificial intelligence for ROM creation and validation we consider specific developments inside ANSYS 3D physics solvers (e.g. Mechanical and Fluent) to easily manage the creation of ROM simulation data and to graphically review ROM results in 3D physics environment.

Static ROM Builder

Static ROM Builder is a module of ANSYS Twin Builder. The main goal of Static ROM Builder is the learning and validation of a reduced order model from nonlinear 3D simulation data. The approach is very general:

- For any type of 3D physics solver including coupled fields, - For any type of inputs. Inputs are scalar parameters including geometrical modifications and fields defined

on the boundary of the domain. - For any type of outputs. Outputs are the fields computed by the 3D physics solver. - Graphic display of fields results.

The ROM could be exported into Twin Builder using FMU format. In addition to core developments using artificial intelligence for ROM creation and validation we consider specific developments inside ANSYS 3D physics solvers (e.g. Mechanical and Fluent) to easily manage the creation of ROM simulation data and to graphically review ROM results in 3D physics environment.

System Modelling

Ansys develop SCADE Architect as a system modelling tool. SCADE Architect is based on SysML and is dedicated to system engineering. In addition, SCADE Architect has configuration capabilities. In particular, it has a dedicated AUTOSAR configuration allowing for Software Component level design. SCADE Architect is connected with medini for safety analysis and with SCADE Suite for detailed design.

Safety Analysis

Medini is dedicated to functional safety analysis. It is one the most widely used tool for such analysis. Analyses cover all classical safety analyses in a model-based approach. With that approach, any modification from one analysis is directly seen on other analyses. The tool read SysML description and can import various architecture modelling. The safety analyses are done in the ISO 26262 context, but other analyses can be performed in the context of semi-conductors or cyber-security. Indeed, medini has been tailored for these different kind of analyses, while preserving the advantages of the model-based approach.

Design & Code Generation

SCADE is a full environment dedicated for the development of safety-critical embedded software. The toolset is made of:

SCADE Suite: this tool is used for the design phase. Algorithms are captured using the Scade language. Scade is a DSL specifically designed for embedded control application, based-on data-flow semantics with control capabilities (state-machines). Both data-flow and control-flow constructs are part of the language and can be freely mixed in a familiar way.

SCADE Suite KCG: it is a Scade to C code generator. KCG is developed following the standards (all artefacts are available) : ISO 26262, DO-178C, EN 50128, IEC 61508, ..

SCADE Test: the tool allows for developing functional tests at model level and to run the tests at the model level. We ensure that 100% of structural coverage implies 100% of code coverage, while keeping the benefits of code generation optimizations. The very same tests can be run on targets, using dedicated harnesses to validate the final object code execution.

SCADE LifeCycle is a bundle of modules to ensure models to requirements traceability as well as automatic certified report generation.

The use of the toolchain alleviates or suppresses (while still fulfilling them) specific verification / validation activities. Using SCADE there is no need for code review nor back-to-back testing for instance.



Driving Simulation

Using VRX Driving Simulator, powered by SCANeR ™, a complete simulation of the vehicle, the software, the sensors, and the environment is possible. The simulation can also support integration with HiL component. The simulation components can come from different sources thanks to VRX integration capabilities.

Simulations can be conducted with a high-level of accuracy as sensors or environment are modelled following physics-law. Special effects like sun glares or radar reflectance can be observed and decision on control design can be taken. The design of the scenarios can be therefore connected with the safety and SOTIF analyses performed using medini.

In addition, the SCADE Vision tool can be used to assess robustness of perception algorithms. Basically, SCADE Vision can be used to detect edge-case situation that are hard to find. The tool uses the user-defined algorithm with its test data-base and exercises the data-base by “tweaking” the data to exhibit potential failure in object recognition.

3.2.1.3 Standard and regulation

The ANSYS tools complies to ISO 26262, SOTIF, AUTOSAR for the automotive part. They comply with DO-187C, DO-330, IEC 61508, IEC 68880 for other domains, including aerospace & defence, ground transportation and industry.

3.2.2 Towards qualification

3.2.2.1 Justification plans aligned with CPS needs

Cyber Physical Systems (CPS) are a new generation of systems combining intensive connectivity, embedded computing and local intelligence, to create a link between the physical and digital worlds and allow cooperation between systems. To achieve these goals Reduced Order Models generated by ANSYS could be assets in:

Platform engineering: fast and reliable « what-if-analysis » as a mean of interactive predesign tool and multi-objective detailed optimization

System engineering: managing as system level the virtual 3D field data

Real-time digital twin: bring a full physic description and control capability into an embedded system.

3.2.2.2 Justification plans aligned with UC requirements

The use case requirements from WP8 in terms of simulation and digital win generation are aligned with our developments. More precisely simulation and digital twin tools to be developed by ANSYS in T5.2 will be used:

1. Material Flow Planning and Optimization (TRUMPF) 2. Automatic Vacuum System (LEONARDO) 3. Thermoplastic Production Line Monitoring (LEONARDO) 4. Aircrafts Health Management System (LEONARDO)

3.2.3 Contribution

3.2.3.1 Related tasks and/or use-cases

TwinBuilder is a software gathering multiple ROM creation and enrichment capabilities offering a system solver managing causal and acausal flows, a Modelica ready compiler with model concatenation properties, a rapid interface creation from ANSYS SCADE and the different ROM builder from ANSYS.



3.2.3.2 Functional description and QoS properties

To build a system easily and quickly, Twin Builder combines the power of a multidomain systems modeler with extensive 0D application-specific libraries, 3D physics solvers and reduced-order model (ROM) capabilities. When combined with embedded software development tools, Twin Builder allow the reuse of existing components and quickly create a systems model of the studied product.

To validate this system and ensure expected performance, Twin Builder combines multidomain systems simulation capabilities with rapid human-machine interface (HMI) prototyping, systems optimization and XiL validation tools.

To connect the created twin to test or real-time data, Twin Builder easily integrates with industrial internet of things (IIoT) platforms and contains runtime deployment options, allowing you to perform predictive maintenance on your physical product. It is the only product that offers a packaged approach for your digital twin strategy.

Building the Twin

Reduce engineering time to build an accurate physics-based twin twice as fast through model reuse and easy composition with Twin Builder’s:

Support for multiple modelling domains and languages

Extensive 0D application-specific libraries

Third-party tool (including 1D) integration

3D ROM creation and integration

Embedded software integration

Validating the Twin

Validate an accurate representation of your product multiple tools are available:

Multidomain simulation with integrated post-processing

Rapid HMI prototyping

Systems optimization

XiL integration

Deploying the Twin

The twins generated by twinbuilder quickly connect to supported IIoT platforms

3.2.3.3 Standards and regulation

Our tools are supporting both FMU/FMI formats as well as Modelica. A special attention was dedicated to the creation of file open, simple and well described file formats to harvest data from solvers and enable a simplified ROM creation process.

3.3 CEA

3.3.1 Background

3.3.1.1 Overview

CEA has a strong background in methods and tools for the specification, design, implementation and validation of safety critical systems.


CEA has extended background on developing tool-supported engineering methodology to build safe embedded systems. Below, we present an example of an engineering methodology based on CEA tools that covers the



following main phases: requirement modelling and analysis, system modelling, analysis and validation, code generation and integration, static code analysis, dynamic (at runtime) code analysis, system qualification and certification.

Requirement modelling and analysis. The primary stage in a safe-by-construction engineering process targets the requirements management, including the activity of moving from the world of ideas into quality requirements. This activity relies on the following principles: (1) Capture ideas as requirements and express those requirements as models; (2) All the stakeholders must be able to read and understand these models; (3) All manners and all levels of structuration and detail must be allowed to adapt to the needs of the client. Our tool, Maât Requirements Efficiency (MRE) is a requirement analysis tool that can help achieve this activity. MRE uses semi-structured templates to capture requirements, and a glossary to list particular entities who have specific roles. The tool provides the possibility to refine the requirements while preserving the fact that they are easily readable. Once one has written the requirements using the MRE grammar, the tool allows displaying a graphical representation of those requirements. This graphical representation can potentially reveal unclear sequences and other errors that would be difficult to spot in textual format.

System Modelling. In this phase, first, the functional requirements of a system are used for specifying the system design as a UML model. The design model has the structural and behavioural aspects of the embedded system. The structural aspects can be specified using component or class diagrams, while interactions, state machines and activity diagrams can capture the behavioural aspect. The Papyrus modeller is used for creating and editing the system design model. Real-time properties can be specified as a cross-cutting concern on every view. In particular, it is possible to specify complex real-time properties and requirements using the syntax of the ARTiMon tool which is supported by Papyrus Moka. In addition to the UML model, a Simulink model can be generated from the UML model. The idea behind this transformation step is to enable the specification of the system behaviour details such as control algorithms that cannot be captured by UML diagrams in Simulink. The details are necessary in modelling the system’s dynamic behaviour to avoid ambiguity and for supporting the model analysis.

System Validation. A UML model can be validated either by simulation or symbolic execution. For validation by simulation, the model is turned into an executable version using fUML or PSCS. Then, Papyrus Moka interprets the executable model for validating the system’s high-level model visually. For validation by symbolic execution, Maât Design Validation help ensure consistency of the design and the designer's intention. The tool allows checking that refined model is compliant with higher-level abstract model and that any system’s property is always true in all possible executions.

Safety analysis. For analysing safety of an embedded system, Sophia is introduced as a Papyrus extension. It is based on systems that are designed with Papyrus modeller (e.g. SysML). Sophia has the following objectives:

Supporting the specification of the safety properties in the architectural model of the system. To afford model-based engineering of safety. It enables the automatic calculation of some safety parameters. Providing an environment for the system development in which all requirements at the same level of

abstraction are compatible and parent requirements are decomposed into children requirements correctly. The requirements are then verified using a safety analysis technique.

In a system development, the system design model contains the non-functional requirements of the system such as safety, security and timing. The design model can be analysed by the safety engineers to define safety evaluation metrics that are assessed across different safety analyses (e.g. FMEA, FTA). The use of the same model for design and safety analyses avoids interpretation mistakes [1]. The model components are annotated with the possible failure behaviour specified as a set of failure modes. Later, the design model is converted into formal models to compute qualitative and quantitative fault trees (FTs).

Code Generation. Based on the design model (validated by simulation and analysed for safety), a code that corresponds to the validated model is generated. In the modelling phase, we have UML and Simulink models. Thus, the code generation is performed from the two models. First, the code corresponding to the Simulink model is generated through Matlab Simulink Coder. Second, the UML model is used for generating the system code together with wrappers for the generated Simulink code using Papyrus Software Designer. Finally, to make the system fully functional, an existing (legacy) code is integrated with the generated code through wrappers. This code generation



and integration step is performed automatically.

Static Code Analysis. In this phase, the integrated code produced by the code generation phase is analysed statically to verify the system safety properties using the Frama-C platform. The platform’s inputs the generated code annotated with the safety properties. These properties are produced by hand as ACSL assertions. The code is then processed automatically by abstract interpretation of the EVA plugin of Frama-C. The plugin computes sets of all possible values for variables of the code under analysis. Based on these values, it warns the system developer about the possible run-time errors (i.e. violations of safety properties).

Dynamic Code Analysis. In addition to the static analysis of the generated code, a dynamic analysis is also performed to verify properties that cannot be proven statically. To do so, the binary code is analysed dynamically by memory fault injection and monitoring techniques. The faults are defined taking into account the system profile. The embedded code is analysed by a virtual platform, i.e. UNISIM-VP [2] as shown in Figure 2. To analyse embedded code with the platform, the different fault scenarios that can occur during the real system execution are first specified. Second, the faults are injected into the simulated system. Finally, the system execution is observed to ensure that it is going to execute correctly in the real situations (i.e. ensuring its reliability [2]). Two timestamped traces are generated as simulation results: instructions trace, and monitored data trace. These traces are compared with the functional traces (without fault injection). The result is used as data support during reliability quantification. The goal is to determine the level of robustness by analysing the effects of the injected fault and its occurrence probability. In case that the system does not react correctly to the injected faults, i.e. the system enters a faulty state, the simulated system is updated with corrective actions to cope with this fault as shown in Figure 2.

Embedded

System

Simulator

Monitor and

Data AnalyzerTest bench

Faults

Scenarios

Inject Fault

Reference

Failure?

Update Simulated System

Yes

NoSilence

Figure 2 - Fault-injection and impact analysis

The UNISIM-VP framework is a simulation, validation and testing framework. This framework is built around a library of hardware components models developed as transaction-level models in SystemC. In addition to the hardware components models, a series of services and third-party tool interfaces may be plugged to the models to ease software validation. Using all these components, UNISIM-VP allow assembling virtual platforms simulating complex electronic systems, while still being able to perform non-intrusive rich instrumentations on software code.



The central component library includes many of the processor simulators around the most popular instruction sets (ARM, Intel and PowerPC). UNISIM-VP framework offers its own software validation-oriented services. Each UNISIM-VP processor simulator responds to a series of standardized interfaces for connecting debuggers, profilers and other instrumentation tools. These validation services are also designed to be extensible while keeping a reasonable additional cost at runtime. With the UNISIM-VP instrumentation mechanisms, it is possible to associate additional information to any data processed in the system, realizing any dynamic tainting analysis needed. The same instrumentation mechanisms may also allow to actively operating on processed data to perform fault-injection or fuzzing.

Finally, the UNISIM-VP virtual platforms are accompanied by interfaces to numerous test and debugging software. This interfaces allow to UNISIM-VP simulator to integrate (or to be part of) other models. These interfaces use either, code instrumentation or hardware components interfaces to bind other models or simulators. These interfaces allow building complex simulators from heterogeneous models that does not necessarily share the same view of the components (service, functional, transactional, electronics…).

ServicesHardware

ComponentsModels

Third PartyTools

Interfaces

■ Test

■ V&V

■ Debugger(s)

■ Code profiling

■ Monitoring

■ Trace analysis

■ Code Sanitizing

GNU GDB

DWARF

ML507 Board S12XDP512 Board

■ System on Chip/Boards

■ Processors

■ Interconnects, memories, peripherals

http://unisim-vp.org



Compliance Monitoring. In addition to the previous analysis techniques, The Maât System Compliance tool that relies on relies on symbolic execution techniques can be used for offline testing to assess compliance of an observed system execution trace with regards to its behavioral design model. The tool can also generate test skeletons from design model models to check real system properties or behaviors. On another hand, the ARTiMon monitoring tool can be used to analyse in a black box manner the conformity of the simulation or execution traces with respect to the real-time properties specified in the design model.

System Qualification and certification. CEA has developed additional features around Papyrus tool for standard automatic model generation, project process tailoring, user guidance during model-based product development, evidence management and compliance measurement (see Figure 3).

Figure 3 - Papyrus features for compliance management of CPS Systems.


The tool chain supports several standards:



OMG UML, SysML, MARTE, fUML, PSCS, PSSM standards

AUTOSAR standard

ISO26262 standard

3.3.2 Contribution

The CEA toolchain presented in the previous section is implementing a “correct-by-construction” process for safety critical systems. However, neither the process nor the toolchain supports the development and integration of artificial intelligence (AI) components. In WP5, CEA target to work on tool-supported approaches for specification, conception, testing and certification of AI-based systems. We will also study how AI can help improve the existing tools and toolchains for development of such systems.

3.3.2.1 Functional description

The expected results for the integration of AI in and for CPS development are twofold:

- Integration of AI in development tools in order to provide advanced assistance for CPS developers; - Evolution of processes and tools to take into account specificities of AI components and enable their

integration in trustworthy CPS.

Below, we detail the different axes towards which we will address these two objectives.

- Integration of AI in development tools in order to provide advanced assistance for CPS developers. o AI augmented design

Requirements analysis is the first phase of system and software engineering cycle and it is essential for the success of the software development process. Software requirement specifications are often expressed in natural language, which is understandable by stakeholders. One of the goals of requirements analysis is to organize them into hierarchical clusters. These clusters constitute a mean to identify the main packages of a software architecture. Thus, automating requirements clustering would be a first step towards a tooled assistance for software architectures design. Automating clustering of requirements written in natural language is not straightforward, due to the richness of natural languages and requires the use of Natural Language Processing (NLP) techniques that have several limitations. CEA aims at developing an automated approach for software requirements clustering in order to help the developer in the design phase by automating the transition from an unstructured model of software requirements into a UML architectural model denoting a preliminary software design architecture using NLP techniques.

o AI augmented conformity with respect to requirements

The problem of asserting conformity with requirements is linked to the requirements elicitation (and testing) process. We propose a tool-aided methodology to help writing structured human-readable requirements. The structuration allows to generate high-level behavioral views of the designed system and to identify potential issues with the requirements at an early stage. For the moment, the process of refining raw text requirements into structured requirements is manual, and we plan to use NLP techniques to help produce a glossary from a specification document written in natural language.

o AI augmented validation with respect to robustness A deep neural network (DNN) is a graph of artificial neurons (graph nodes) connected by artificial axons (graph edges), exhibiting a multiple-layer organization. Learning a DNN is a matter of finding the correct weighting of each neuron's inputs so that the operation cascade leads to the correct output result. Unfortunately, reasoning about these DNN is challenging due to their black-box nature: it is difficult to understand what the network does and even harder to tell the meaning of each individual weight. Moreover, it has been discovered that neural nets can sometimes exhibit surprising non-robust behaviors, for instance, by classifying two very similar inputs (e.g., images that differ only in brightness



or in one pixel) to different labels. In order to identify and understand non-robust behavior, a lot of research focuses on using numerical precision analyzer to propagate ranges of numerical values and numerical perturbations over a software code. These numerical analyzers involves, either static code analysis that struggles to scale or dynamic code analysis that often leverage complex code instrumentations (or dedicated programming languages). For dynamic code analysis, tools to allow programming-language-agnostic numerical analysis for DNN will be developed. Our DNN analyzer will rely on compiled binary version of a source code and on its execution in instrumented UNISIM-VP simulators. The instrumented simulators will follow every DNN-processed data, tracking the impact of any initial perturbation. Working on binary code simulation will have the extra advantage of (1) validating the final executable (no intrusive monitoring) and (2), being independent of the source code language.

- Evolution of processes and tools to take into account specificities of AI components and enable their integration in trustworthy CPS.

o Methods for AI components design

Within Machine Learning (ML), deep learning has gained much traction since several high-profile success stories. Unlike classical computer reasoning, the statistical method by which a neural network solves a problem can be seen as a very primitive form of “informal reasoning” as opposite to classical computer reasoning. However, so far the only real success of deep learning has been its ability to self-tune its geometric logic that transforms data represented as points in n-dimension, to data represented as points in m-dimension (if we provide enough training data). Unlike human beings, a neural network does not have the ability to reason through algorithmic logic. Furthermore, although neural networks are tremendously powerful for a given task, any deviation in the input data may give unpredicted results, since they have no ability to achieve global generalization. It limits their reusability. Considering the significant cost associated with neural network development, integrating such systems is not always economically viable. It is therefore necessary to abstract, encapsulate, reuse and compose neural networks. Although lacking in deep learning, algorithmic logic and abstraction are today innate to classical software engineering through programming primitives, software architecture paradigms, and mature methodological patterns like Model-Driven Engineering. We propose to blend reusable algorithmic intelligence, providing the ability of computer reasoning, with reusable geometric intelligence, providing the ability of “informal reasoning”. To achieve such an objective, we can explore some ideas like integrating programming control primitives in neural networks, applying software architecture paradigms in neural networks models and assembling modular systems using libraries containing both algorithmic modules and geometric modules.

o Methods and tools for AI components runtime management through uncertainty measurement

The lack of understanding of how DNNs work, coupled with the difficulty of verifying the correctness of DNNs, has led to erroneous behaviours and unexpected fatal consequences, mainly caused by highly confident incorrect predictions. Uncertainty estimation offers a potential solution for failure prediction in safety-critical systems that include ML components by explaining what a model does not know in terms of its prediction confidence. However, DNN models fail to capture correctly the uncertainty in their predictions. Although many approaches have been proposed to quantify DNN model uncertainty, it is still a challenging task. In practice, uncertainty estimation methods carry significant computation cost and latency that is not suitable for runtime failure detection or prediction. In addition, assessing the quality of these uncertainty estimates is not a simple task since there is not a direct ground truth available. In order to address the previous issues, is important to identify, compare, and assess uncertainty quantification methods for DNNs that are suitable for meeting the needs of safety-critical systems. Later, runtime monitors and error detectors could be designed for these components to foresee NN failures and trigger proper warnings or take the entire system to a fail-safe behaviour/state.



o Formal methods for AI components

Neural network are used in domain where we do not know how to describe well the problematic, so the technique use a lots of examples to create the NN and test it. In order to gain assurance on the behavior of the neural network outside the examples, we need to specify properties that the NN must verify. However, since the problematic is hard to describe the properties are also difficult to specify. We propose to develop a visualisation tool and a checking tool. The visualization tools will help to get a high-level view of the computation done by the NN and help him find domain of inputs where it behaves badly. These bad domains of the inputs will give new examples for training the NN. Moreover, this high-level view will allow the expert to find properties that will be checked by the tool. Again if the property is not verified it gives new examples for the learning. We will primarily focus on use-cases with a small number of inputs, such as decision making from a small number of sensors.

o Methods for AI assurance Systems integrating AI modules require, depending on the application envisaged, suitable qualification / certification processes that has not yet been the subject of industry standard recommendations. Indeed, the qualification of an AI system does not stop with its entry into operation. Corrective or evolving increments may be necessary in order to adapt to changes specific to the deployment context. This situation actually occurs already for safety critical systems, e.g. in avionics and automotive domains, but it is even more critical of AI-based systems, particularly in the case of specific systems called self-learners. We deem important to study, formalize and integrate very early in the process of specifying qualification guides and standards the notion of incremental and evolving qualification, throughout the operation of learning and self-learning systems. We target to address the following challenges: (1) the high frequency of modifications (data obsolescence, operating environment, platform which leads to impending requalification process; (2) the characterization of risk assessment techniques for an affordable breakdown of the incremental qualification problem; (3) the need of a highly modular AI architectures to ensure that modules and its modifications remain independent of the qualification of the entire system as much as possible; (4) the complexity of the validation process of AI module which induce important requalification costs with a slightest function modification; (5) the considerations for the interpretability / explicability of AI (XAI) in the context of an evolving qualification approach.

3.3.2.2 Non-Functional and QoS properties

The overall contribution addresses the trustworthiness (including safety and cyber-security) and performance properties of AI systems.

3.3.2.3 Related Tasks and/or use-cases

We will develop the CEA contribution in T5.1, T5.3, T5.4 tasks. Several use cases rely on AI-based technologies and could be the basis to extract concrete scenarios to validate our work. The following table gives the UC [provided in WP7, WP8 and WP9] where AI-based techniques are explicitly taken into account or if they could be used either for their development or embedded in it.



WP UC# Name Related description Stated AI usage Implicit AI usage Potential contribution

WP7 UC1 (Valeo)


See title No No N/A

WP7 UC1 (Thales)

Secure connectivity subsystem

See title.

No No N/A

WP8 UC1 (Trumpf)

Material flow analytics and simulation

See title.

No

There is a “3d acquisition of a digital shop floor model with automatic semantic annotation”. Automatic semantic annotation could involve AI-based techniques.

(to be confirmed)

WP8 UC2 (WIKA) Collaborative Lifting (a.k.a. Mobile CPS)

Coordination of 2 mobile lifting machines

AI-powered algorithms are stated to help coordination of 2 mobile lifting machines.

Supervision & execution: “Possibility of autonomous execution of the lifting process”.

“The machines will be able to communicate with the control centre, in this case a remote system/application (cloud application) and they will be able to communicate with each other as well, to exchange relevant information to a safe execution of the collaborative lifting process”

NA

AI augmented design and conformity (to be confirmed): MDV could be useful when modelling and simuating the lifting process. The next stage is generating lifting missions/contracts for every crane. MSC could be applied here to help validate those.

WP8 UC3 Automatic “create concurrent CPS able to synchronize their relative

No AI techniques could be used for “the synchronization between the

Method for AI assurance: (to be



(Leonardo) Vacuum System position and avoid any possible collision with other CPS”

two CPS and the collision avoidance system between CPSs and between CPS and mounted structure”.

confirmed)

WP8 UC4 (Leonardo)

Trimming Quality Improvement

“make CPS collect data coming from sensor on part, machine and environment in order to determine parameters to be set not to have defects. Data collection and analysis is in fact the main purpose of the overall system: the algorithm will continuously improve and trimming activities consequently will be more reliable and safe”. Moreover, “This use case needs to analyse big amount of data in real time and to address the statistical correlations between variables”.

No

AI techniques could be used for the sensing and correlation parts with respect to the real-time and safety/reliability properties.

Method for AI assurance: (to be confirmed)

WP8 UC5 (Leonardo)

Thermoplastic production line monitoring

“This CPS will gather all information from production plan and it will schedule parts. Moreover it will monitor temperature of ovens, parts and pressing mould and pressures of entire process and correlate data with DSC of parts understanding and preventing from any process drifts”

No AI techniques could be used for the sensing and correlation parts with respect to the real-time properties.

Methods and tools for AI components runtime management through uncertainty measurement (to be confirmed)

AI augmented conformity: MRE has been identified as useful to help write the requirements for this use case.

Method for AI assurance: (to be confirmed)

WP8 UC6 (Leonardo)

Aircrafts health management system

“gathering, collecting and analysing data concerning aircraft fleet maintenance”. It

No

AI techniques could be used to manage the big amount of data and for Troubleshooting (identification)/Trend Monitoring

(to be confirmed)



focuses on ground framework. (“receive advices when thresholds are superseded and define a maintenance task accordingly”)/ Predictive-Preventive maintenance/Spare Management. There is no identified real-time/safety constraints.

WP9 UC1 (RTE)

Distributed controls for transmission network

Managing (i.e. monitoring and controlling) an energy-based network.

No

AI techniques could be used to manage the big amount of data and for monitoring and diagnosis/optimization. There are strong constraints on security and reliability, especially unavailability management.

AI augmented design and AI augmented conformity (to be confirmed): The Use Case requirements must be written at a level of detail sufficient to enable CPS4EU designers to design components and pre-integrated architectures to satisfy those requirements, and testers to test that the system satisfies those requirements. To help writing these requirements, MRE would be useful.

WP9 UC1 (Schneider)

Safety report for critical function

Embedding in the RTE’s UC1 a “Software Defined Edge Control”. It “consists in replacing the classical protection relays (i.e. IEDs) by a new distributed solution, minimizing the complexity of the field equipment of an electrical substation, and relocating the complex treatments in servers at the Edge level”. (edge = very close to the sensors/actuators)

No No N/A

WP9 BME

CPS based flow chemistry modules with predictive

Description not found NA NA N/A



maintenance technologies for Pharma 4.0

WP9 Airlane


See title Yes To be confirmed

WP9 Arcure


See title Yes NA To be confirmed

WP9 ACOEM


See title Yes NA

Methods and tools for AI components runtime management through uncertainty measurement (to be confirmed)

WP9 M3S

Open Loop testbench allowing the validation of the developed sensor for Automated Driving applications

Description not found NA NA




As of today, there is no standard addressing the certification of CPS using AI-based systems. With our work in CPS4EU, we expect to contribute to any future standard project for such systems. CEA is involved in the working groups for the establishment of the ISO/IEC JTC 1/SC 42 for artificial intelligence. Results of these standardization activities will be integrated into the CPS4EU developments.



CEA contribution aims mainly to address the challenges to support seamless and smooth integration of AI in CPS. We will investigate method and tools for design and validation of AI-based systems both in design and operation phases. The CPS also exhibit stringent requirements in terms of safety, security, performance. We will take into account these aspects including the need for interpretability and explainability of AI by sketching out a methodology to ensure trustworthiness of AI-based systems in a certification purpose.


In the following section, we write out the requirements of the use cases and we justify the plan to tackle them.

For the use cases WP7/UC1 (Valeo) and WP7/UC2 (Thales), we do found associated requirements.

The defined requirements of the use case WP8/UC1 (TRUMPF) do not exhibit an explicit need for an AI integration. A priori the use case is not addressable by CEA contribution.

The use case WP9/UC1 (RTE) do not exhibit an explicit need for an AI integration. A priori the use case requirements are not addressable by CEA contribution.

The use case WP9/UC Arcure do not exhibit an explicit need for an AI integration. A priori the use case requirements are not addressable by CEA contribution.

For the use case WP9/other SME’s UC, we do found associated requirements.



WP8/UC2 (Leonardo):

UC2-FNC-01 Functional Requirement

Modelling and Simulation Modelling and Simulation of lifting process and the used machines Medium

Modelling and simulation could be evaluated with Papyrus tooling.

UC2-PRF-01 Performance Requirement

Real-time operating system Using real time operating system (Linux-RT) High


Lifting process monitoring duty cycle Duty cycle of the lifting monitoring task must be under 1s Medium

Papyrus4robotics for the modelling can be used to evaluate his Linux-based ROS2 code generation feature.


Autonomous lifting Autonomous execution of the lifting process Low


AI for winch control sensor (camera/ lidar based sensor) AI-powered sensor platform for the winch control Medium

CEA contribution on uncertainty evaluation could be applied if AI algorithms are used for autonomous execution.

The use case WP8/UC3 (Leonardo) do not exhibit an explicit need for an AI integration. A priori the use case requirements are not addressable by CEA contribution, but it should be confirmed, e.g. regarding the following requirement:


Real-time communication and execution DRILL and VACUUM must cooperate in real time (under 1s) Medium

The use case WP8/UC4 (Leonardo) do not exhibit an explicit need for an AI integration. A priori the use case requirements are not addressable by CEA contribution, but it should be confirmed, e.g. regarding the following requirement:


Real-time communication and execution The system should provide the operator with information in real-time (under 1sec) to enable the operator to adjust the settings of production machine

Medium

The use case WP8/UC5 (Leonardo) do not exhibit an explicit need for an AI integration. A priori the use case requirements are not addressable by CEA contribution.

WP8/UC6 (Leonardo):



UC6-FNC-12 Functional Requirement Maintenance Model The system should discover and implement a model to allow the automated identification of the information required to perform maintenance activities (troubleshooting, removal/installation procedures, etc.)

High

UC6-FNC-13 Functional Requirement Trend monitoring Model The system should identify trend deviation of critical parameters High

UC6-INT-07 Interface Requirement Maintenance Operator Interface The System shall guide the maintenance operator in his troubleshooting activity High

UC6-INT-08 Interface Requirement Engineer Interface The System shall provide the Engineers with trend analysis information High

It should be confirmed if AI techniques used for UML model recognition could be re-used here



3.4 INRIA

3.4.1 Background

3.4.1.1 Overview

THEMIS is a framework to facilitate the design, development, and analysis of decentralized monitoring algorithms; developed using Java and AspectJ (~5700 LOC). The THEMIS framework is further described in its companion tool paper [3] and demonstrated on its Website [4]. It consists of a library and command-line tools. The library provides all necessary building blocks to develop, simulate, instrument, and execute decentralized monitoring algorithms. The command-line tools provide basic functionality to generate traces, execute a monitoring run and execute a full experiment (multiple parametrized runs). The purpose of THEMIS is to minimize the effort required to design and assess decentralized monitoring algorithms.


THEMIS provides an API for monitoring and necessary data structures to load, encode, store, exchange, and process observations, as well as manipulate specifications and traces. These basic building blocks can be reused or extended to modify existing algorithms or design new more intricate algorithms. To assess the behaviour of an algorithm, THEMIS provides a base set of metrics (such as messages exchanged and their size, along with computations performed), but also allows for the definition of new metrics by using the API or by writing custom AspectJ instrumentation. These metrics can be used to assess existing algorithms as well as newly developed ones. Once algorithms and metrics are developed, it is possible to use existing tools to perform monitoring runs or full experiments. Experiments are used to define sets of parameters, traces and specifications. An experiment is effectively a folder containing all other necessary files. By bundling everything in one folder, it is possible to share and reproduce the experiment. After running a single run or an experiment, the metrics are stored in a database for post-mortem analysis. These can be queried, merged or plotted easily using third-party tools. After completing the analysis, algorithms and metrics can be tuned so as to refine the design as necessary.


THEMIS does not comply with any regulation.





THEMIS covers several aspects related to the challenges that need to be addressed while designing, implementing and deploying CPS.

As CPS are in essence distributed and cooperating systems, THEMIS is the only tool dedicated to monitoring that explicitly account for the decentralized and distributed nature of such systems. It can be used to monitor safety requirements on the connections between objects and the system and evaluate global properties hold on the system while not disrupting the existing architecture.

Moreover, THEMIS and monitoring in general is an effective technique to provide complementary trust in the system by supplementing existing verification techniques that would not scale.

Finally, THEMIS can also contribute to augmenting the safety of systems by providing some form of automation in the use of fail-safe fall-back mechanisms on systems.


The efficacy and novelty of THEMIS lies in its handling of decentralized systems. By analysing the use cases provided by the partners, we identified two such situations where THEMIS can be used, namely UC2 in WP8 and UC1 in WP9. We describe below, for each of such UC, how THEMIS can be used.

Regarding UC2 in WP8, Mobile CPS, THEMIS can be used for the monitoring of the collaborative lifting system at control center and more precisely at the level of the digital twins of the cranes. It can be used for monitoring the global internal state by checking health condition on the various modules of the twins. THEMIS can also be used for ensuring the correct execution of the planed lifting process. As such, we target primarily the functional requirements of the use case, and in particular UC2-FNC-03, UC2-FNC-04, UC2-FNC-05, and UC2-FNC-06.

Regarding UC1, in WP9, Distributed Controls for Transmission Network, THEMIS can be used in the operations domain by contributing to the monitoring and diagnostic, and more specifically by providing alerts in case of abnormal conditions. The use case currently use a distributed architecture where the functions of the automata are distributed between several components. Most of the requirements are functional. Some of the requirements involve timing aspects (such as UC1-FNC-08-10) whereas as of now THEMIS does not support real-time but could support a limited notion of time through using internal clocks.

3.4.3 Contribution


We describe below, for UC2 in WP8 and UC1 in WP9, how THEMIS can be used.

Regarding UC2 in WP8, Mobile CPS, THEMIS can be used for the monitoring of the collaborative lifting system at control center and more precisely at the level of the digital twins of the cranes. It can be used for monitoring the global internal state by checking health condition on the various modules of the twins. THEMIS can also be used for ensuring the correct execution of the planed lifting process. As such, we target primarily the functional requirements of the use case, and in particular UC2-FNC-03, UC2-FNC-04, UC2-FNC-05, and UC2-FNC-06.

Regarding UC1, in WP9, Distributed Controls for Transmission Network, THEMIS can be used in the operations domain by contributing to the monitoring and diagnostic, and more specifically by providing alerts in case of abnormal conditions. The use case currently use a distributed architecture where the functions of the automata are distributed between several components. Most of the requirements are functional. Some of the requirements involve timing aspects (such as UC1-FNC-08-10) whereas as of now THEMIS does not support real-time but could support a limited notion of time through using internal clocks.




THEMIS could serve in identifying the satisfied and not satisfied functional requirements by means of monitoring when the system is in operation. The monitors obtained from THEMIS could run either on execution traces or while the system is running, provided compatibility of the execution environment.

Upon the detection of violation of functional requirements, THEMIS could be used to decide where to apply corrective actions or modifications to the component states. For this purpose, we should design a theory of enforcement for decentralized system. As of now, THEMIS only provides detection means. Henceforth, we need to integrate on THEMIS some decision procedures for enforcement as well as the design of enforcement strategies.


Since THEMIS handles only specifications with propositional events and atomic propositions, non-functional properties (which require handling of data or time) are not primarily targeted.


We plan to adapt THEMIS to standard and regulations as per needs expressed by the partners of the use cases.

3.5 SHERPA-ENGINEERING

3.5.1 Background

3.5.1.1 Overview

Sherpa Engineering, an innovative SME (95 persons), is a System Engineering Company specialized in modelling and control system design. Sherpa Engineering provides a tool-based methodology for the design, the evaluation and the validation of complex cyber-physical systems (CPS).

Our engineering offer is based on a software suite with PhiSystem (SysML based) for system description and PhiSim for simulation evaluation.


Figure 4 - Phi-Suite, a Model-Based Methodology for System Design & Evaluation

Phi-Suite is a tool suite for system design and evaluation of CPS that support the process flow shown in Figure 4. It



consists on four main phases: system definition, simulation design, simulation model development and system evaluation and analysis.

System definition. PhiSystem, a tool developed with CEA-LIST, is a customization of Papyrus (SysML graphical editor) and is used for a multi-viewpoint definition of complex systems: purpose, key functions and structural definition. PhiSystem ensure the link between architecture, requirements and validation tests.

Figure 5 - An Internal Block Diagram for architecture definition

The formalism used in PhiSystem also ensures a fast and accurate link with simulation models, and thus supports System Definition by anticipating simulation in early phases.

Simulation design. PhiSystem also provides tools to extract specific information from the system model and to build a simulation architecture.

Figure 6 - Simulation architecture extracted from the system model

Simulation model development. PhiSim is a set of libraries of system level models which are specialized by applicative domain.



Figure 7 - A block diagram for digital simulation

For energetic systems, PhiSim provides a tool for designing and simulation of an energy management system and a set of models which represent energetic equipment (motor, exchanger …) and energetic functions (powertrain, thermal synthesis …). For autonomous vehicles, PhiSim provides a specialized framework including the main control algorithms (perception, localization …).

System evaluation and analysis. PhiSim also provides a comprehensive set of reference-standard algorithms and workflow apps for data processing, analysis, visualization, and algorithm development.

Figure 8 - Post-processing and system analysis tooling




OMG SysML for system definition

FMI-FMU is a tool independent standard to support both model exchange and co-simulation of dynamic models

Modelica an object-oriented, declarative, multi-domain modelling language for component-oriented modelling of complex systems



3.5.3 Contribution

The main objective of Sherpa Engineering is to develop a generic platform for modelling and simulating complex systems. It shall be instantiated on any market segment and any application type. Focus is made on mission and control system.


Task 5.2: Contribution to the design of the process/tool chain for CPS. Definition of a model-based design workflow for complex system and control systems

Task 5.4: Development of tool interface with system modeller for multi-level simulation. Integration in Sherpa tool Phi-Suite.


Figure 9 - A generic platform and its instantiation on market segments: automotive and smart grid

The content of the platform is illustrated in the Figure 9. The expected outcomes of this tool-chained methodology are:

System architecture: include the requirement definitions and the functional and physical solution definition. This model ensures the link between architectures, requirements and validation tests.

Simulation model: used for system analysis, this model includes physical and control parts, environment model and scenarios description. Post-processing tools shall be developed to verify the design properties at a system level.



Control system: in this methodology, the control system is first defined at system level. The control model, developed in specific language (as Simulink) will be integrated in the simulation model for MIL (Model in the Loop) validation. Some standard tools will be used for code generation and SIL validation.

The tool-chained must also comprise all the transformation tools as:

Simulation context generation based on the system definition

Component (model) specification based on the simulation architecture

Composite simulation model integration

Simulation trace management and post-processing

Properties extraction and verification


N/A


N/A

3.6 UGA

3.6.1 Background

VERIMAG has been developing the BIP (Behavior, Interaction, Priority) component framework for about 12 years. Component-based systems in BIP are modeled by composing atomic components (that is, the behavior as extended automata with code) with multiparty interactions and restriction through dynamic priorities. BIP has a formally defined operational semantics, which underlies all the analysis, transformations and implementation techniques and therefore, supports the development of rigorous model-based design flows. Recent research expands the original framework to increase its adoption for additional categories of systems and/or application domains featuring real-time and stochastic systems. The characteristics of the BIP framework are as follows:

- component-based, providing a family of operators for building composite components from simpler components. This overcomes the poor expressiveness of theoretical frameworks based on a single operator, such as the product of automata.

- model-based, describing all software and systems according to a single semantic model, explicitly modeling architecture and interactions between the various components

- tractable, guaranteeing correctness by construction and thereby avoiding monolithic a posteriori verification as much as possible.



3.6.1.1 Overview


The design flow involves four distinct steps that translate the application software into a BIP model to analyze and progressively derive an implementation by applying source-to-source transformations:

1. Translating the application software into a BIP model. The translation focuses on the definition of adequate interfaces. It encapsulates and reuses the application software’s data structures and functions. Automatic translators exist that parse Matlab, C, and Simulink.

2. Integrating architectural constraints in the application software model. The integration derives a system model in BIP from a model of the hardware target platform and a mapping.

3. Translating interactions and priorities of the system model in terms of protocols using send/receive primitives.

4. Generating deployable C++ code from which an implementation can be obtained. The transformations are “correct by construction” because the obtained BIP models are observationally equivalent to the original model. In particular, they preserve the application software’s safety properties.

In addition to ensuring correct-by-construction code generation of BIP models, it is also possible to perform compositional verification on the model to ensure safety properties are applicable. This is mostly accomplished with the DFinder tool.

The D-Finder tool implements a compositional method for the verification of component-based systems described in BIP language encompassing multi-party interaction. The compositional approach allows for first generating invariants at the component level for each atomic component, and then combining these invariants, in a



compositional manner based on the interactions between such components. Component invariants are generated by analyzing the behavior of the component for a given property to infer the invariants. The efficient computation of such invariants requires precise symbolic computation of reachable states. This is done using quantifier elimination where appropriate and an over-approximation of the behavior using syntactic analysis. Interaction invariants express global synchronization constraints between atomic components. They are derived by deriving finite abstractions of atomic components and analyzing the obtained petri-net representing their communication. D-Finder can be used for deadlock-detection. It applies proof strategies to eliminate potential deadlocks by computing increasingly stronger invariants. Relevant extensions to the BIP framework for CPS4EU include:

The Real-Time Stochastic extension of BIP (RT-BIP) allows for representing component-based models with behavior subject to timing constraints. In this setting, components are extended timed automata and composition is done through multiparty interactions and priorities. Timed models are prevalent in many application domains and we used RT-BIP as the common denominator for all our research activities involving real-time aspects namely compositional verification, schedulability analysis, code generation, simulation, performance analysis, etc. Stochastic models are of paramount importance in system design as they allow to capture uncertainties in system behaviour and to account for variability induced by system environment. Such models offer, in addition, a mean for high-level reasoning and for dealing with complex systems in an abstract and quantitative fashion. This is highly recommended, especially during the first phases of the design process, where the number of design choices is quite large. The stochastic real-time BIP extension (SRT-BIP) provides the necessary modeling features for representing a rich class of stochastic real-time models. In this setting, components are stochastic timed automata where actions are associated both with timing aspects (enabling conditions, urgencies) and with stochastic constraints (discrete probabilities and/or probability density functions). Component composition is done through multiparty interactions and lead to models having a well-defined stochastic semantics in terms of Generalized Semi-Markov Processes. SRT-BIP models are utilized for performance evaluation and risk assessment of systems models from different application domains.

The Statistical Model Checking BIP (SMC-BIP) implements several well-known statistical analysis algorithms, namely hypothesis testing, probability estimation, rare events for assessment of stochastic models. SMC-BIP supports several formalisms for expressing stochastic properties (LTL, MITL), operates on stochastic models with different semantics (DTMC, CTMC,GSMP) and further includes an IDE providing project management, model edition, compilation, and simulation for enhanced usability. Dynamic Reconfigurable BIP (DR-BIP) is intended for programming reconfigurable systems encompassing various



aspects of dynamism. DR-BIP focuses on enabling dynamic interactions within BIP. DR-BIP introduces the higher-level concept of architectural motifs to structure the architecture of a system and to coordinate its reconfiguration at runtime. An architectural motif defines a set of interacting components that evolve according to reconfiguration rules. With DRBIP, the dynamism is captured as the interplay of dynamic changes in three independent directions 1) the organization of interactions between instances of components in a given configuration; 2) the reconfiguration mechanisms allowing creation/deletion of components and management of their interaction according to a given architectural motif; 3) the migration of components between predefined architectural motifs which characterizes dynamic execution environments. A key feature for DR-BIP is the possibility to monitor a holistic view of a system’s behavior captured as a set of traces involving two alternating execution phases: dynamic reconfiguration and execution of interactions in a static architecture.


The BIP framework and its extensions do not comply with any regulation.



UGA contribution will focus on utilizing its tool-chain for the modeling, simulation, and analysis of the systems presented in the use-cases (in the context of Task 5.4), providing tooling support for the design and verification of trusted CPS. This includes the usage of scalable methods for the formal verification of safety properties of CPS.


The BIP framework allows us to model and derive properties of correctness with respect to the application of functional requirements of the systems. Functional requirements that focus on correctness are of high relevance, our particular focus will be on UC2 and from WP8 tackling collaborative lifting and UC1 from WP9 tackling distributed controls for transmission network due to their focus on correctness of the collaboration of various CPS and the additional realtime constraints from WP9 UC1. It remains to be investigated if WP9 UC1 needs dynamic modeling since in its operational requirements (OPR-08), it is stated that new sensors may join the network seamlessly. This would warrant utilizing DR-BIP for modeling such behavior. The use case UC3 from WP8 tackling the automatic vacuum system is also a relevant candidate, as it would be of interest to study the collaboration protocol in itself between the DRILL and VACUUM. Alternatively, verifying that actions are taken in the correct order and time is also an interesting avenue to explore. Further investigation needs to be taken to see how to integrate the complex models for the DRILL and VACUUM with the BIP framework for analysis. The below table summarizes the relevant use-cases along with their functional requirements.



3.6.3 Contribution


Task 5.4: CPS Tools specifications of trusted systems WP8 UC2: Collaborative Lifting / Mobile CPS WP8 UC3: Automatic Vacuum System WP9 UC1 (RTE): Distributed Controls For Transmission Network


The BIP framework along with its extensions and tool-chain provide the following: - Component-based modeling of systems explicitly defining architecture and communication between its

various components. - Simulation and exploration of BIP models. - Modeling of real-time stochastic systems (RT-BIP). - Statistical model checking used for the analysis of properties and assessment of stochastic real-time

systems (SMC-BIP). - Modeling of dynamic and reconfigurable systems (DR-BIP). - Analysis of properties and behavior of dynamic and reconfigurable systems (DR-BIP). - Correct-by-construction distributed code generation of models expressed in BIP for rapid prototyping or

development.


Ease-of-use: the Statistical Model Checking BIP (SMC) extension of the BIP framework provide a GUI editor and features for simplifying the task of writing models and properties for real-time stochastic systems. Automation: the tool-chain provides automatic code generation and model exploration which is useful for rapid-prototyping which provides a good basis for iterating, exploring and refining usecases. Correctness: correctness-by-construction is at the core of the development of the BIP framework and remains an important requirement for trusted systems design.


N/A

3.7 EUROTECH

3.7.1 Background

3.7.1.1 Overview

Eurotech is a cyber-physical systems manufacturer and an industrial IoT solution provider. Eurotech is involved in the industrial use cases (WP8 – UC3, 4, 5 and 6) lead by Leonardo and, in these use cases, it will be responsible for the IoT-based infrastructure devoted to edge computing, data collection, systems and enterprise software (e.g. cloud platform) integration.

The IoT-based infrastructure is composed of a hardware platform conceived for edge computing and of a software integration platform for hardware abstraction, data collection and processing on the edge, and devices remote control, fleet management and systems integration on the cloud or on premises. The platform also provides a



complete and developers-friendly environment for the implementation of the business logic, that is, the use case specific application that partially runs on the edge and partially on the enterprise side.

The IoT-based infrastructure provides tools for the use case development and management through the IoT integration platform, but it also requires tools to support the management of the infrastructure across its lifecycle. The IoT-based infrastructure provides tools for:

Edge computing

CPS integration

Simulation of the industrial gateways composing the IoT infrastructure

Monitoring and remote control of the gateways and of CPS integrated in the IoT infrastructure

The IoT-based infrastructure requires tools for:

The software development of the IoT integration platform (IDE, compiler, debugger, …)

The software development of specific business logics on the edge and on the enterprise side (IDE, compiler, debugger, …)

Monitoring and remote control of the IoT infrastructure


Depending on the phases of the engineering process, the set of adopted tools has to provide the following functionalities:

Functional design: o Kura WIRES has been conceived to simplify the definition of simple business logics on the edge.

Kura WIRES adopts the dataflow programming model to graphically define dataflow graph, that is graphs where the nodes represent specific abstraction of the devices or of any specific unit of work. The nodes interact together to collect, store and process data on the edge of an IoT infrastructure.

Figure 10 - An example of data flow programming

Procurement & engineering: o A Java software development toolchain (IDE, compiler, debugger, virtual machine, …) must provide

the tools for the IoT platform development, test and debugging. o An Abstraction Layer SOA Service allows the developer to abstract from the hardware technical

details and simplifies the development of a business application on the edge of an IoT infrastructure.

o A Device Virtual Twin allows to simulate a device (e.g. the industrial gateway) deployed on the edge of an IoT infrastructure and simplifies the test and debug activities of the device itself, of the IoT



platform and of the business logic associated to a specific vertical application.

Deployment & commissioning: o Kapua Web Console is used to manage the deployment of a fleet of devices in an IoT installation. It

allows to remotely manage and control the deployment activities, including the certificate management, the geo control of deployed devices, the support for the operator in charge of installations and the management of the accounting of the entire fleet (e.g. users, groups and their permissions).

o Kura Provisioning Service is used to manage provisioning on the edge of a fleet of devices in an IoT installation

o The Device Virtual Twin can be used to simulate the deployment process of devices on the edge of an IoT infrastructure.

Operation & management: o Kapua Web Console primary role is to provide remote management and control functionalities on

the fleet of devices in an IoT installation during operations.

Maintenance, retirement & recycling o Eventually, Kapua Web Console simplifies and automates the remote management of maintenance

activities (e.g. firmware updates, faults detection, etc.) and of the retirement process of the fleet of devices in an IoT installation.

Figure 11 - Kapua web console


Kura and Kapua are developed using Java 8 (Open JDK ver. 8), OSGi and the Eclipse IDE. Both for telemetry and command/control, the communications are based on MQTT an open OASIS and ISO standard (ISO/IEC PRF 20922) associated with WebSocket protocol (IETF as RFC 6455 and WebSocket API in Web IDL in the process of standardisation by the W3C) and SSL (Secure Sockets Layer) for security.

The rest API follows the OpenAPI 3.0 Specification (formerly Swagger Specification).

Finally, Kura supports several standard protocols for field communications: e.g. S7, Sense HAT, Modbus, OPC-UA, IEC60870, BACNet, etc.





The nature of IoT is strongly heterogeneous and distributed and requires specific tools to manage a fleet composed of a large number of different devices, specifically during the deployment, operation, maintenance and retirement phases of the lifecycle.


The tools are required for the management of the lifecycle of the IoT infrastructure adopted in the industrial use cases developed in WP8 (UC3-6), which follows the concepts of Industry 4.0 for the digitalisation of manufacturing plants in the aeronautic domain.

3.7.3 Contribution


The activities related to the IoT integration platform are carried on in WP6, but single contributions to specific technology areas are localised also in WP1 (e.g. the Hardware Abstraction Layer), WP2 (e.g. the communication technologies), in WP3 (e.g. field protocols and sensors support) and WP4 (e.g. the actionable data management). This tasks distribution reflects the multidisciplinary and multi-technology nature of the IoT integration platform that covers all the layers of a typical IoT stack.

The activities related to the adoption of the IoT integration platform in the use case are carried on in WP8.


From a functional perspective, Eclipse Kura provides the following functionalities and features on the edge:

• An IoT gateway management application • A hardware abstraction to simplify application development • A rapid data flow programming tool • An application container for edge computing and IoT gateways • A secure container for Java and OSGi-based application • Full support and easy access to widely adopted industrial protocols

• A unified and simple cloud platforms connector

Its counterpart Eclipse Kapua, operates on premises or on the cloud and provides:

• M2M secure communication and connectivity management • Telemetry management • Relational and non-relational data storage • Alters and actions • Remote control and management console • Fleet and device management • User management • Platform security • First level data analytics and dashboards • Rest API for integration with existing enterprise software platforms


The IoT integration platform with its tools has been conceived to reduce the costs of IoT infrastructures in industrial



environments, improving both the design and development costs and the operative costs. The remote management and control functionalities simplify, automate and improve the quality of the job of the administrator of the IoT infrastructure, reducing significantly the possibility of human errors. The hardware abstraction layer significantly improves the quality of the develop software, allowing the developer to focus on the business logic rather than on the low-level technical details.


Eurotech is part of OASIS, the body in charge of MQTT standardisation.

3.8 EMX

3.8.1 Background

3.8.1.1 Overview

emmtrix Technologies is a tool provider for the semi-automatic parallelization and code generation for embedded heterogeneous multicore systems. With the two tools emmtrix Code Generator (eCG) and emmtrix Parallel Studio (ePS), a workflow from model-based designs like MATLAB® or Simulink ® or directly from C code to parallel C code for the target platforms is provided.


Figure 12 - Overview of emmtrix workflow

Figure 12 shows an overview of the emmtrix workflow. The first part “Code Generation” is responsible for converting the input MATLAB®/Simulink® or Scilab/Xcos to plain C code. This generic C code is sequential and not optimized for a particular target platform.

When starting with C code, this conversion is not needed. ePS takes the C code and offers a graphical user interface to semi-automatically parallelize the application. With the help of a hierarchical program view, users can set constraints and stay in control of the parallelization process. Mapping and scheduling is handled automatically while honouring the constraints set by the user. Communication and synchronization instructions are inserted automatically in a programmatic way to ensure the correct functionality without the introduction of dead locks or race conditions.

The output of ePS is parallel C code optimized for the selected target platform. With the help of a template system, the code can easily be integrated into larger systems. Common supported platforms are ARM Cortex-A, Infineon AURIX and PowerPC processors. More complex systems with GPUs or FPGAs can be addressed by generating

GPU

Multicore

FPGA



OpenCL/CUDA code or optimize the C code for the use with high-level synthesis tools.

In the context of CPSs, the emmtrix tools can be used to migrate existing algorithms developed in either MATLAB®, SIMULINK®, Scilab or C to different target platforms while using the available hardware resources as best as possible. With the support for the pre-integrated architectures from WP6, switching between the different platforms can also be done easily as long as all required sensors and actors are available.

Figure 13 - Overview of GUI of emmtrix Parallel Studio


As input, eCG supports MATLAB® and Scilab scripts or Simulink® and Xcos models. As output, it generates ANSI C or C99 code, with some minor additions from C++11. ePS supports as input ANSI C or C99 with respect to the Misra C coding standard.



The emmtrix tools cover several challenges that needs to be addressed while developing for CPS.

Modern multi- or many-core processors, occasionally paired with additional accelerators for special instructions, can cover the performance requirements of state-of-the-art applications like AI or computer vision. However, programming them is not an easy task and brings with it a couple of new challenges for the programmer that don’t exist in traditional sequential systems. Topics like race conditions, deadlock or synchronization are hard to fix when problems occur. The emmtrix tools can be used to optimize the code for these systems and greatly reduce the development time with automization.

Regarding the safety requirements of CPS, emmtrix is working on a qualification kit for the emmtrix tools. It will enable advanced reporting and tracing capabilities as well as a checker tool to ensure the functional equality of the input and the generated parallel output code. In doing so, the parallel code generation capabilities of the emmtrix tools can be used for safety-critical applications when the original sequential code is already qualified. The



development is not part of CPS4EU, but can be provided when required.


EMX can assist the development for the different use cases in the following way:

To develop the applications with safety requirements for WP7, the emmtrix tools can potentially assist with the migration of the code to the pre-integrated architectures.

Same goes for the development in WP8. For the use case of WIKA, the emmtrix tools will be adapted to support ROS that will be used on the target platform.

For WP9, the emmtrix tools can be used to support the HiL tests by easily generating the C code required for them.

3.8.3 Contribution


Task 5.4: EMX will adapt the emmtrix tools to support a workflow for CPS that can be used to target the pre-integrated architectures defined in WP6. As leader of this work package, EMX will also propose tool chains using tools from all partners from WP5 to cover the special development requirements of the use cases. The tool chains will cover different topics like simulation, development with safety and security requirements, design of CPS and development of special algorithms used in the use cases.

Task 6.2: The emmtrix workflow will support the pre-integrated architectures from WP6 by defining them in an architecture description language. This flexible approach allows the configuration of the used platform as well as switching between them when necessary.

In addition to that, the toolchain is planned to be used by WIKA and TUC for their use cases. They will use the Robot Operating System (ROS) on the target platforms and require tool assistance to generate the required code. The emmtrix tools will be adapted to generate the code that can run on ROS.


The expected results of the project from the point of view of emmtrix cover two different topics:

On the one hand, the existing model-based emmtrix tool flow will be adapted to the pre-integrated target platforms as defined in WP6. This contains the extension of the existing hardware abstraction layer to also support the special needs of CPS development like support for specific sensors and actors and the interconnectivity of said systems. The goal is to get the most performance out of the hardware platforms in order to support the development of the applications like AI and computer vision.

On the other hand, the generated output C code of the tool chain will be adapted to the requirements of the use cases. On the more abstract level, this covers topics like safety and security requirements. More concrete, this also covers the generation of code to use with ROS from use cases from WIKA and TUC and potentially HiL testing for the WP8 use cases.


The abstraction from the actual hardware allows users to optimize applications for the pre-integrated architectures with very little knowledge about the target platforms.


In the context of CPS4EU, emmtrix is not involved in progressing the support for any specific standards or regulations.



3.9 TUC

3.9.1 Background

A simulation scenario is defined as the specification of initial and terminal conditions, significant events and the environment as well as the major entities, their capabilities, behaviour and interactions over time [5]. Scenario development is an extensive process beginning with the stakeholders’ descriptions of the scenario and finishing with the generation of the corresponding executable specifications [6]. Scenario development starts with operational scenarios, mostly in text form constructed in natural language by domain experts. They usually present the key information from the user’s perspective and are often not complete and consistent. Operational scenarios are then used to develop conceptual scenarios, essentially to be based on a metamodel, either an explicit or an implicit one. The result is then a complete and a consistent scenario specification, often compiled in a table. Finally, conceptual scenarios are transformed into executable scenarios for target simulation environments using a set of rules specific to the target simulation environment [7].

Scenarios are the key elements in simulation-based verification of CPS. However, there is no common understanding about the elements and the structure of these elements in a scenario. This leads to deficiencies in communication and presenting test scenarios, sharing and reusing them, verifying and validating them and prevents the development of common infrastructures for scenario development and execution.

In order to boost reusability and shareability of scenarios among stakeholders for collaborative development and testing of CPS, TUC will leverage standardization efforts in aerospace and automotive domains for a broader general-purpose simulation scenario definition language.

Figure 14 - Open Scenario Infrastructure

The open scenario infrastructure will make use of System Entity Structures (SES) based approach to model scenario elements. SES is a declarative knowledge representation scheme that characterizes the structure of a family of models in terms of decompositions, component taxonomies, and coupling specifications and constraints [6]. SES enables a fundamental representation of a hierarchical modular model providing a design space via the elements of a system and their relationships in hierarchical and axiomatic manner. SES supports the development, pruning, and generation of a family of hierarchical simulation models. Pruning defines a process of selecting a subset from a hierarchical level. This results in a selection-free tree called as a Pruning Entity Structure (PES).



Figure 15 - Scenario development approach

We follow the scenario development approach that employs an SES-based metamodeling that was proposed by Durak et al. in [8]. As illustrated in Figure 15, at the metamodeling level, the SES metamodel captures all SES constructs and their relationships (i.e. Entity, Specialization, Aspect, MultiAspect, and Attribute). Conforming to the SES metamodel, the scenario metamodel is defined to capture all possible meta elements of the domain scenarios. Finally, a scenario model, defined using the scenario metamodel provides scenario-specific values. Scenario modeling is a pruning operation which prunes the scenario metamodel that is formalized as an SES.


3.9.2.1 Early process description

The following process illustrates the workflow of TUC in collaboration with WIKA and Emmtrix.

Figure 16 - Workflow

Initially, TUC will work with WIKA for development for methods to use simulated drone to assist in collaborative lifting. TUC will prepare a corresponding simple executable scenario in XML which will be converted to a Gazebo simulator-based XML file to validate the process.


The open scenario infrastructure will be used for testing of a multitude of scenarios by using SES to prune and generate a specific executable scenario. The executable scenario is parsed to a Gazebo instance for verification and validation.



3.9.3 Contribution


Task 5.2: Open Scenario Infrastructure to boost reusability and shareability of scenarios among stakeholders for collaborative development and testing of CPS. Leveraging standardization efforts in aerospace and automotive domains for a broader general-purpose simulation scenario definition language and supporting tooling.

The language and tooling will be used in WP7 by VALEO in use case democar, in WP8 by WIKA in Collaborative Lifting use case.

3.9.3.2 Functional Description

To generate a scenario, we use the XML based approach for simulation scenario development in three levels as depicted in Figure 15. At the metamodeling level, there are two important steps in the conceptual space. A particular SES is built using the constructs, structure and axioms of SES, what we call an SES Ontology. Then, Pruned Entity Structures (PESs) are obtained from this particular SES via pruning operations. PESs are eventually XML instances.

The first step is applied to the language specification in the domain modeling level. The Simulation Scenario Definition Language is defined as an SES that captures all possible scenario elements, their relations as well as their attributes. The representation of Simulation Scenario Definition Language SES is then the Simulation Scenario Definition Language XML. It then can be written to an XML Schema either manually or programmatically.

The second step is then applied at the scenario modeling level. In the conceptual space, we regard that a particular simulation scenario is a PES that is obtained from pruning the Scenario Definition Language SES. In the executional space, the Simulation Scenario Definition Language XML has computational representation as an XML schema, where each simulation scenario is then an XML instance.



Figure 17 - Simulation Scenario Development

The following example illustrates a sample scenario.

The aircraft is directly overhead the waypoint DF444 of the ROLIS7N transition to runway 07L (RWY 07L) with an altitude of 5000 ft implies that the latitude is 49.959911° North, the longitude is 7.815608° East and the altitude is 1524 meters. It appears in the scenario XML as follows:

<Entity>

<Aircraft>

<Flight>

<Position latitude="49.959911" longitude="7.815608"/>

...

</Flight>

...

</Aircraft>

</Entity>




1) Platform Independence of the open scenario infrastructure 2) Interoperability – The infrastructure uses XML as executable scenarios. They can be adapted to work with

different simulation. [9] has demonstrated this with Unity. For this project, we will use Gazebo simulator.


XML (eXtended Markup Language) to exchange scenarios

3.10 TRUMPF

3.10.1 Background

3.10.1.1 Overview

TRUMPF develops a smart factory simulation framework (see Figure 1) for evaluating logistical targets (e.g. throughput times, throughput, delivery reliability, stock inventory, …) in sheet-metal industry. Simulation is the discrete event simulation of manufacturing systems. TRUMPF uses the software AnyLogic which combines discrete-event and agent-based simulation modelling methods. The latter is particularly suitable for modelling the complex material flows and decentralized decision-making in sheet metal production.

The smart factory simulation framework consumes the data of real-time factory input (e.g. material location and flow, shop floor plan with geofences, machine information) using technologies provided through WP3. We combine this data with context information from other sources like Enterprise Resource Planning (ERP) or Manufacturing Execution Systems (MES). A concrete goal with this framework is to derive factory models with close to zero manual work, which is an extreme improvement over what is common today in a typical factory process consulting project (details are given in the TRUMPF use-case UC 1 in WP8).

We consider CPS for deriving simulation inputs. Therefore, we examine how data from an indoor-localization system (=CPS) can be used during input modelling. The mobile markers of the indoor localization system are attached to production orders. All movements are tracked and analysed. This should give us, for example, an understanding of the underlying principles of factory control.

Figure 18 - Smart Factory Simulation Framework




We create a smart factory simulation framework that reduces manual labour during simulation model generation and parameterization.

The framework can be used to run simulation experiments to evaluate logistical targets o if machines are replaced or changed o if control strategies are changed

We develop analyses in Python using indoor-localization data, where the analysis results can be used for simulation model generation and parameterization.

We will train neural networks in Python to predict process times. The trained models will be included into the simulation framework.


AnyLogic is available for free under a personal learning license. Special license offers are available for academia. Further information can be found here: https://www.anylogic.de/downloads/ Python is available for free under the GNU GPL (General Public License). We make use of CMSD XML-standard [10] for data exchange between the different data sources and the simulation framework. The different analyses of the CPS data return their result into an intermediate database (“input data” in Figure 18) which is compliant to CMSD. From this intermediate database, the building blocks in the model library are then parameterized.


3.10.2.1 Early process description

The information about which machine is located where in a factory hall is a result of the hall scan analyses by ACS plus from WP3. This information is to be integrated into the simulation framework via an exchange format. In the first step, a suitable exchange format will be specified, which contains all information that can be extracted from the hall scan. This information can then be used to generate the simulation model. A prerequisite for this is that a block of the machine is available in the block library.


All analyses and results directly contribute to WP8 UC1 - MATERIAL FLOW ANALYTICS AND SIMULATION

3.10.3 Contribution


WP8 UC1 - MATERIAL FLOW ANALYTICS AND SIMULATION

The smart factory simulation framework is a core component within the UC1 to evaluate logistical targets.

WP3 Our framework consumes data from CPS, e.g. Indoor Localization System (Tasks 3.1 and 3.2)

Our framework reads an exchange file with information on the manufacturing system (What is Wher?) which is derived from a hall scan with the analyses developed by ACS plus


Functional Requirements:

https://www.anylogic.de/downloads/



1. Find out which simulation inputs can be derived from indoor-localization data from CPS 2. Check if other (CPS) data sources from WP3 are of interest for manufacturing simulation 3. Recognize material flow control principles from indoor-localization data 4. Develop framework which serves to:

- use CPS data to create initial simulation model - use CPS data to keep simulation up to date - decrease time for simulation model generation


Ethical Requirement:

- Ensure that the data analyses do not allow conclusions to be drawn about individual employees. - Ensure that the data analyses are compliant with the ethical guidelines of German data ethics

commission

Usability Requirement:

- Developed data analyses are easy to use: Load data, press play, get result file which is input for manufacturing simulation.

Interface Requirement:

- Definition of interface for data exchange between data analysis environment and simulation environment.

- Definition of interface for data exchange between hall scan analysis and simulation environment.

3.11 UNA

3.11.1 Background

The chair for Software Methodologies for Distributed Systems at the Faculty of Applied Computer Science with 12 to 15 Ph.D. students, has its focus on the development and operation of software intensive systems including business as well as embedded systems, e.g. in Automotive. The group has strong co-operations with leading companies like BMW, Nokia and Continental. Beyond there are cooperation with many SMEs. In particular, the group has led a network on perspectives for embedded systems with 15 SMEs in the last years.



The chair is involved in several research projects in the area of embedded systems, like ARAMiS II where the group is in the project management team as well as is leading a work package. Moreover, projects in the area of Model-Driven Engineering for Safety Critical Systems, test the test, reducing test complexity for embedded systems, contract-based model-driven engineering and cognitive approaches for mobile networks are executed. At the moment there are concrete plans for a spin-off in the area of architecture mining, architecture analysis and optimization

3.11.1.1 Overview

The University of Augsburg will contribute to the development of concepts for architecture modeling and analysis techniques of different sources, i.e. monitoring information into the (open) architecture of CPS. Moreover, concepts will be invented for contract-based modelling and analysis of open system architectures. Being the basis for design time verification for networked CPS, safety and security analysis on the architecture level will be developed.

Concepts for the prediction of performance aspects based on the system architecture and monitoring / trace information will be developed and ways for optimizing architectures will be shown. The results will be supported by prototypical implementations to support the case studies and show the applicability of the approach. The implementation will be based on the tooling of the University of Augsburg. In addition, contributions to open and verifiable pre-integrated architecture analysis, including security and safety by design, will be made available for the integration into the toolchains of the partners.

3.11.1.2 Main Feature

UnA focuses on architecture analyses deployable in planning and design phases for CPS systems. These analyses are able to check multiple attributes, states or conditions, depending on the analysis types. In plenty other applications fields, like enterprise architecture management, architecture analyses are already used frequently and successfully. However, in case of CPS systems the choice of architecture analyses are limited. Therefore, UnA aims in adapting already existing analysis approaches to make them suitable for CPS needs. As analyses are also suitable for diverse goals and goal types, different analyses are required to cover all CPS concerns.

To deliver a rough overview of the main features and significant functions which UnA plans, a short description part is given:

● UnA is steadily working on diverse architecture analyses. For the CPS4EU project UnA will focus on the analyses with a green background (see figure) which are: - Design Analysis - Analysis with extended influence diagrams (EID) - Availability and availability weak points analysis - Risk Analysis - Security Analysis - Analysis of dependencies and impact analysis - Analysis of interfaces - Service Interoperability Analysis

● Analysis with grey backgrounds are also possible further CPS architecture analyses for future project activities

● Provided analyses will be used to evaluate design flaws or diverse aspects depending on the analysis type and goal type



● The final selection of architecture analyses which will be provided is not finalized yet but includes

presumptively: ○ Threat Analysis ○ Failure Availability Impact Analysis ○ Safety and Security Analysis for architectural decision support

○ Service Interoperability Analysis ○ UnA focuses on the safety and security field in CPS systems: To be able to evaluate vulnerabilities,

flaws will be identified with a Graphical Pattern Recognition Framework (PRF) ○ Structured knowledge preservation to enable review by multiple users ○ Automated flaw identification through PRF ○ Pre-step for flaw assessment ○ Flaw identification by categories

○ Static Application Security Testing: Vulnerabilities in software come from poorly written code.



Often, programmers are not even aware of the loopholes they create. One solution to this problem is Static Application Security Testing (SAST). SAST can be used to analyze source code or binary files for vulnerabilities. UnA focuses on general and CPS-specific security vulnerabilities and provides a set of rules to check whether the program code is vulnerable or not



As described in section 2 of this deliverable, diverse CPS4EU use cases require different tool needs. UnA planned tools satisfy the needs of following use cases:

WP Use Case Name Tool Need

WP7 UC1 Safe and enhanced positioning with inertial navigation unit

Safety and security analysis

WP7 UC1 Secure connectivity subsystem Security analysis

WP8 UC2 Collaborative Lifting (a.k.a. Mobile CPS)

Modelling tools

WP8 UC4 Trimming Quality Improvement Failure analysis

WP9 UC1 Distributed controls for transmission network

Modelling tools for IoT architectures

Safety and Security analysis

WP9 ARCURE: Pedestrian detection on off-

Road Construction trucks based in the Artificial intelligence with the Vision technology

Safety analysis

WP9 ACOEM: Monitoring network for Environment Quality (well-being) and Threat Detection in one big European city

Threat detection


In the following section, UnA writes out the requirements of the use cases and justifies its plan to tackle them. There, only use cases are listed of which some requirements are served by the tool.

3.11.2.3 WP8

3.11.2.3.1 UC2 - Mobile CPS [WIKA]


Modelling and Simulation Modelling and Simulation of lifting process and the used machines

It is planned that the tool can be used to visualize and monitor the digital twin of the physical component of a use case.



UC2-SEC-01 Security Requirement

Secure connection to the control centre and to other machines

the connection to the control centre should be secured by encryption and authentication

Trust in parties is partly defined by confidentiality, integrity and authentication which can be technically tackled by encryption. As part of the planned feature set of UnA, the tool may be used to evaluate the trustworthiness of members of a system. This score-based evaluation system is partially influenced by the encryption level of connections between members.

3.11.2.3.2 UC3 - Automatic Vacuum System [LDO]


Communication Security Communication between DRILL and VACUUM shall support data integrity and allow authentication of the two parts


Communication Reliability Communication should ensure delivery and quality of data transmission against interferences (e.g. noise, disturbances and/or frequency constraints on plant)


3.11.2.3.3 UC4 - Trimming Quality Improvement [LDO]


Communication Security Support for mutual authentication, data integrity and confidentiality


Communication Reliability Communication should ensure delivery and quality of data transmission against interferences (e.g. disturbances and/or radio frequency constraints of the production floor)


3.11.2.3.4 UC5 - Thermoplastic Production Line Monitoring [LDO]


Communication Security Support for mutual authentication, data integrity and confidentiality




Communication Reliability Communication should ensure delivery and quality of data transmission against interferences (e.g. disturbances and/or radio frequency constraints of the production floor)


3.11.2.3.5 UC6 - Aircrafts Health Management System [LDO]


Secure connection The System shall provide a secure wireless connection.


Secure Communication The System communications shall be encrypted during data transfers


UC6-INT-03 Interface Requirement

Data and Data Flow standardization All the Data and Data Flow shall be standardized

The tool relies on state-of-the-art communication protocols to assess the given architecture of use cases. The model of a use case will be editable which can be further used to analyze the impact of changing communication protocols on the system.

3.11.2.4 WP9

3.11.2.4.1 UC1 - distributed controls for transmission network [RTE]

UC9-DSG-04 Dependability No more than one unwanted order shall be sent every 10 years.

Trust in parties is partly defined by integrity which can be technically done by encryption. As part of the planned feature set of UnA, the tool may be used to evaluate the trustworthiness of members of a system. This score-based evaluation system is partially influenced by the encryption level of connections between members.

3.11.3 Contribution

The next generation of systems - namely cyber-physical systems - open up new ways of attacking a system. For this purpose, UnA aims at providing a tool to accomplish secure cyber-physical systems by design.




UnA contributes by developing a meta model in WP1 that is aligned to the cps-specific architecture. In addition, requirements and application constraints are examined. Based on this meta model, UnA creates conditions for safety and security analysis on the modeling level in T5.3 and will integrate its tool into the toolchain in T5.4. Some of the analysis are especially developed for UC2 of WP8.


As described before UnA focuses on architecture analyses and their methods. To get a better understanding, afterwards a few functional details to the main features and their required methods respectively foundations are given:

○ Pattern Recognition Framework (PRF) ■ A pattern recognition framework includes security- and safety-specific templates to define and

preserve positive design patterns or negative anti-pattern ■ PRF will be realized as domain specific language with the eclipse plugin Xtext ■ Code generation from DSL to compilable code is needed to recognize the defined pattern and

anti-pattern within the CPS model ○ Threat Analyses

■ Threats emerge through attacked vulnerabilities especially design flaws ■ Threats must identified and assessed as early as possible to minimize the risk ■ Quantitative security analysis for evaluation of vulnerabilities exploitation

○ Failure Availability Impact Analysis ■ Failures can cause safety and security issues with unexpected impacts. These impacts and

dependencies must be revealed ■ Probabilistic safety and security analysis to identify effects of attacks or hazard ■ Applicable for multiple quality attributes

○ Safety and Security Analysis for architectural decision support ■ In planning phase multiple design choices are possible. The best suitable architecture must be

identified before implementation ■ Usage of extended influence diagrams ■ Includes defense graphs or fault graphs

○ Service Interoperability Analysis with probability values ■ To enable a flawless communication and working system the interoperability of services must

be checked ■ Probability values estimate the likelihood of service issues and their dependencies

○ Static Application Security Testing (SAST) ■ Code crawling to check whether certain coding standards (i.e. CWE) are met and therefore if

certain code sections are exploitable ● i.e. return of pointer value outside of expected range

■ Protection against zero-day vulnerabilities ○ Trust-based Security Analysis

■ Score-based assessment of trustworthiness of system members ■ Assignment of known vulnerabilities (i. e. CVE) to the operating systems and programs used in

the use cases and assessment of its potential impacts ● commonly known vulnerabilities have a greater impact on the level of trust as potential

vulnerabilities (given by SAST) ■ Determination of weaknesses/vulnerabilities on the architecture level and assessment of its

potential impacts ● i.e. authentication bypass using an alternate path



○ Trust-based Impact Analysis ■ Assessment of impact of code-specific and architecture-specific weaknesses/vulnerabilities on

the architecture ■ Hints on architecture optimization based on flaws

3.11.3.3 Non-functional and QoS properties

Usable The tool is based on established and open-source technologies like EMF and Eclipse Sirius. Because of that, every partner is able to use our tool free of charge.

Scalable The provided analyses are performing with use cases of diverse size. State-of-the-art technologies are used to visualize models of such use cases.

Integratable The tool is capable of being integrated into the partners’ workflow and modelling process. As mentioned before, the provided analyses are applicable if the meta model of WP1 is used. Therefore, the only requirement to use the tool is to have a representative model of a use case.

3.11.3.4 Standards and regulations

At present, no standards or regulations are taken into account. UnA plans to adapt the tool to the needs of the use case providers and thus to involve standards and regulations used by these providers.

3.12 ITI

3.12.1 Background

3.12.1.1 Overview

The main objective of ITI in CPS4EU project is to extend art2kitekt framework with functional simulation capabilities of CPS components and real-time behaviour of the underlying platform (RTOS, processors, etc.), and delivering a hybrid simulation approach for verifying CPS systems. The ultimate goal will be provide flexibility in the definition of scenarios and early verification and validation of complex CPS.


The art2kitekt framework is a web-based tool suite that can be used for modelling Cyber-Physical Systems (CPS) and that provides several analysis techniques that let the engineer know the feasibility of the system on early phases of the production cycle. The user is able to define the hardware of the target system to be analysed, the model of the software that is to be executed on the platform and flexible simulation of scenarios. She is then able to select from different analyses offered by the tool suite, allowing her to analyse different aspects of the model and checking the feasibility of the configurations under study.

The Figure 19 depicts the main areas of work in CPS group. The results of this work are captured by art2kitekt framework. In this project, we will focus our attention on systems simulation and system monitoring.



Figure 19 - ITI: areas of work in CPS group


Modelling capabilities of the art2kitekt toolsuite is based on the standard Architecture Analysis & Design Language (AADL); however, the platform and application model is private. Exporting internal models to AADL is still not implemented but in the art2kitekt roadmap.

The core of the simulation engine and the simulation units are also inspired by FMI standard, however FMI units cannot be imported directly into the simulation framework without building specific wrapper/adapters. In addition, Modelica language and its open library is on our scope in order to integrate easier functional modelling capabilities into the art2kitekt framework.



The aim of ITI work is to develop a toolchain that takes into account functional and temporal behaviour of cyber-physical systems. This will provide more flexibility and accuracy when evaluating the system behaviour using virtual environments.

This toolchain also should use run-time monitoring and mitigation techniques to help in the development of reliable CPS in presence of timing misbehaviours.


art2kitekt is a multi-paradigm simulated an analysis environment focused in cyber physical systems. It allows flexible simulation of scenarios, dynamic and control systems. Therefore, the needs detected on the context of the aircrafts domain, specifically in the design phase, will guide our work during the project.

art2kitekt will support the needs detected on the following points:

art2kitekt allows flexible simulation of scenarios, flight and control systems. The simulated outputs can be showed via viewers or reports and can be keep in a data storage. These data can be analyse to obtain useful information to troubleshooting and preventive maintenance.

Additionally, the art2kitekt framework, through its Quality Management component, allows the engineer to easily generate test plans and test cases in an automatic way, reducing cost and time. The information obtained with these tests can be used to predict possible failures.

The art2kitekt tool suite also provides the runtime monitoring service. It observes the execution of the system under test and obtains its temporal behaviour. This feature allows the operator to monitor aircraft



systems performances. He/she can set customizable threshold in order to receive advices when thresholds are superseded and define a maintenance task accordingly.

Figure 20 shows a diagram of the use of art2kitekt in a flight management system.

Figure 20 - Art2kitekt Framework working for the aircraft domain.

In the next table we can see the tasks that our toolchain is going to perform in order to archive the requirements commented above. Notice that we are currently not involved in any use case but we will take UC6 context to deliver our work.

WP UC# Name

WP8 UC6 System configuration

WP8 UC6 Simulation of scenarios, flight and control systems

WP8 UC6 Generate and run tests

WP8 UC6 Data analysis and data visualization

WP8 UC6 Runtime monitoring service

Figure 21 - Tasks to be developed within Art2kitekt Framework

In each of one these tasks is charge of developing a module into art2kitekt framework. These modules have communication interfaces among them as we can see in Figure 22.

Figure 22 - Module diagram of the software tool.



3.12.3 Contribution


ITI contributes to tasks T5.2 Simulation for CPS and T5.3 trustworthy system engineering. Next section describes in more detail the work to be performed.


Extending art2kitekt framework will involve the following functional items:

System Simulation: a hybrid approach will be developed for verification and validation (V&V) CPS systems, taking into account its functional and temporal behaviour. This extension will provide more flexibility and accuracy when evaluating the system using virtual environments.

Run-time monitoring and mitigation techniques will be investigated to help in the development of reliable CPS in presence of timing misbehaviours. Detection and isolation techniques for HW events that can induce unexpected behaviours especially on multicore platforms will be also considered.

The art2kitekt framework will be also extended to provide automatic code generation of the runtime monitors using the information obtained from the system simulation and analysis.


Some aspects of non-functional properties are taken into consideration when developing modules in art2kitekt framework. Documentation, usability, efficiency, etc., are properties improved in every step of the developing process of the framework. In CPS4EU we will also follow this approach.

Actions for providing Quality of Service of art2kitekt services are beyond this project.


No standards or regulations are addressed in this project, although art2kitekt make use of OSLC standard for the data interoperability with other CPS systems.



4 CONCLUSION

In this deliverable, we have provided an initial analysis of CPS tool needs focusing on the project use cases. The tools of the project participants were described from the two perspectives of the backgrounds and contributions to meet the identified needs. CPS4EU tools have been categorized throughout the product lifecycle using the Arrowhead-Tools project approach. In addition to the technical description, special attention was paid to the qualification and standard means applicable to all the tools.



REFERENCES

[1] N. Yakymets, S. Dhouib, H. Jaber, and A. Lanusse, “Model-Driven Safety Assessment of Robotic Systems,” in IEEE/RSJ International Conference on Intelligent Robots and Systems, IROS’2013, Tokyo, Japan, November 3-7, 2013.

[2] R. Nouacer, M. Djemal, and S. Niar, “Using Virtual Platform for Reliability and Robustness Analysis of HW/SW Embedded Systems,” in 1st International ESWEEK Workshop on Resiliency in Embedded Electronic Systems, In conjunction with Esweek 2015, Amsterdam, The Netherlands, 2015.

[3] Antoine El-Hokayem and Yliès Falcone, “THEMIS: A Tool for Decentralized Monitoring Algorithms,” in In proceedings of the 26th ACM SIGSOFT Symposium on Software Testing and Analysis (ISSTA). ACM,125-135, New York, USA, 2017.

[4] Yliès Falcone, “THEMIS Artifact Repository for ISSTA 2017 paper: Monitoring Decentralized Specifications,” [Online]. Available: https://gitlab.inria.fr/monitoring/themis. [Accessed March 2020].

[5] Topcu, O., Durak, U., Oguztuzun, H., and Yilmaz, L., “Distributed Simulation – A Model Driven Engineering Approach,” in Springer, Cham, 2016.

[6] Durak, Umut, et al., “Computational representation for a simulation scenario definition language,” in AIAA Modeling and Simulation Technologies Conference, Kissimmee, Florida, 2018.

[7] Karmokar, Bikash, et al., “Towards an Open Simulation Scenario Infrastructure,” in ASIM 2018 - 24. Symposium Simulationstechnik, HafenCity Universität Hamburg, 2018.

[8] Durak, Umut, et al., “Using System Entity Structures to model the elements of a scenario in a research flight simulator,” in AIAA Modeling and Simulation Technologies Conference. , Grapevine, Texas, 2017.

[9] Ellis, Oliver, “Simulation Based Development and Verification of Drogue Detection Algorithms for Autonomous Air to Air Refuelling.,” in AIAA Scitech 2020 Forum, Nashville, Tennessee, 2020.

[10]

Simulation Interoperability Standards Organisation, “SISO-STD-008-01-2012 - Standard forCore ManufacturingSimulation Data ─ XML Representation,” 08 August 2012. [Online]. Available: https://www.sisostds.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=36239&PortalId=0&TabId=105. [Accessed March 2020].

cps tools - requirements analysis

Documents