1 Foundational Technology Layers

It is fair to assume that most future software applications will be developed to function as a part of a certain platform, and not as standalone components. In some embedded system domains, this idea has been a reality for a decade (e.g., in the AUTomotive Open System Architecture (AUTOSAR) partnership, which was formed in 2003). Increasingly the platforms have to support SoS and IoT integration and orchestration, involving a large amount of diverse small devices. Guaranteeing quality properties of software (e.g., safety and security) is a challenging task, and one that only becomes more complex as the size and distribution of software applications grow, especially if software is not properly designed for its intended operational context (cf. Chapter 2.3 Architecture and Design: Methods and Tools). Although we are aiming towards continuous integration on the level of IoT and SoS, we are still struggling with the integration of code changes from multiple contributors into a single software system.

One aspect of the problem relates to the design of SoS50, which are assumed to be composed of independent subsystems but over time have become dependent. Orchestration between the different subsystems, that may involve IoT as well, is an additional issue here. Another aspect relates to the certification of such systems that requires a set of standards. This applies especially for IoT and SoS and it is complicated by the introduction of AI into software systems. Although AI is a software-enabled technology, there are still many issues on the system level when it comes to its integration into software systems. It is particularly challenging to ensure their functional safety and security, and thus to certify such systems. Some of the existing initiatives include, e.g. for vehicles, ISO 21448 (Road Vehicles – Safety Of The Intended Functionality (SOTIF)), ISO/TR 4804 (followed by ISO/AWI TS 5083, currently in development), ANSI/UL 4600 Standard for Safety for the Evaluation of Autonomous Products, and SAE J3016, which recommends a taxonomy and definitions for terms related to automated driving. Note, that AI may be applied as an engineering tool to simplify certification.

Finally, integration and delivery practices are part of the engineering processes. Although methodologies already exist to achieve this (such as DevSecOps and ChatOps), these mostly relate to software production. With ECPS, continuous integration becomes increasingly more complex, since the products into which the new software modules have to be integrated into are already sold and ‘working in the field’, often in many different variants (i.e. the whole car fleet of an OEM). Even in domains where the number of variant systems is small, retaining a copy of each system sold at the producing company in order to have an integration target is prohibitive. Thus, virtual integration using model-based design methods (including closed-box models for legacy components) and digital twins used as integration targets as well as for verification & validation by physically accurate simulation are a mandatory asset for any system company to manage the complexity of ECPS and their quality properties. System engineering employing model-based design and digital twins must become a regular new engineering activity.

Europe is facing a great challenge with the lack of platforms that are able to adopt embedded applications developed by individual providers into an ecosystem (cf. Reference Architectures and Platforms in Chapter 2.3). The main challenges here are to ensure the adequate functionality of integrated systems (which is partially solved by the microservices approach), while ensuring key quality properties such as performance, safety, and security (see also Major Challenge 6) (which is becoming increasingly complex and neglected as we adopt approaches that facilitate only integration on the functional level). Instrumental for these challenges is the use of integration and orchestration platforms that standardise many of the concerns of the different parts in the SoS, some of which are connected via IoT. In addition, Automated engineering processes will be crucial to ease the integration of parts.

ECPS will become a part of an SoS and eventually SoECPS. SoS challenges like interoperability, composability, evolvability, control, management and engineering demand ECPS to be prepared for a life as a part of a SoS (cf. Chapter 1.4 System of systems). Thus precautions at individual ECPS's are necessary to enable cost efficient and trustworthy integration into SoS.

Therefore, it is essential to tackle these challenges by good engineering practices: (i) providing sets of recommended code and (system to system) interaction patterns; (ii) avoiding anti-patterns; and (iii) ensuring there is a methodology to support the integration from which the engineers of such systems can benefit. This implies aiming to resolve and pre-empt as many as possible of the integration and orchestration challenges on the platforms design level. It also involves distribution of concerns to the sub systems in the SoS or IoT. Followed by automated engineering processes applying the patterns and dealing with the concerns in standardised ways. Besides this, it is necessary to facilitate communication between different stakeholders to emphasise the need for quality properties of ECPS, and to enable (automated) mechanisms that raise concerns sufficiently early to be prevented while minimising potential losses.

On the development level, it is key to enhance the existing software systems development methodologies to support automatic engineering, also to automate the V&V processes for new features as they are being introduced into the system. This might need the use of AI in the V&V process. At this level, it is also necessary to use of software system architecture in the automation of V&V and other engineering practices, to manage the complexity that arises from such integration efforts (also see Major Challenge 3 below).

The key focus areas identified for this challenge include the following:

• Continuous integration of embedded software:
  • Model based design and digital twins to support system integration (HW/SW) and HW/SW co-development (increasingly new technologies have to be integrated).
  • Applying automation of engineering, taking architecture, platforms and models into account.
  • Virtualisation and simulation as tools for managing efficient integration and validation of configurations, especially for shared resources and other dependability issues.
  • Application of integration and orchestration practices to ensure standard solutions to common integration problems
  • Integration and orchestration platforms and separation of concerns in SoS and IoT.
• Verification and validation of embedded software:
  • (Model) test automation to ensure efficient and continuous integration of CPSs.
  • Enabling secure and safe updates (cf. Major Challenge 3) and extending useful life (DevOps).
  • Continuous integration, verification and validation (with and without AI) enabling continuous certification with automated verification & validation (especially the focus on dependability), using model-based design technologies and digital twins; also when SoS and IoT are involved.
  • Certification of safety-critical software in CPSs.

Complex systems such as airplanes, cars and medical equipment are expected to have a long lifetime, often up to 30 years. The cost of keeping these embedded systems up to date, making them relevant for the everyday challenges of their environment is often time-consuming and costly. This is becoming more complex due to most of these systems becoming cyber-physical systems, meaning that they link the physical world with the digital world, and are often interconnected with each other or to the internet. With more and more functionalities being realized by embedded software, over-the-air updates – i.e. deploying new, improved versions of software-modules unto systems in the field – become an increasingly relevant topic. Apart from updates needed for error and fault corrections, performance increases and even the implementation of additional functionalities – both optional or variant functionalities that can be sold as part of end-user adaptation as well as completely new functionalities that are needed to respond to newly emerging environmental constraints (e.g. new regulations, new features of cooperating systems). Such update capabilities perfectly fit and even are required for the ‘continuous development and integration’ paradigm.

Embedded software also has to be maintained and adapted over time, to fit new product variants or even new product generations and enable updateability of legacy systems. If this is not effectively achieved, the software becomes overly complex, with prohibitively expensive maintenance and evolution, until systems powered by such software are no longer sustainable. We must break this vicious cycle and find new ways to create software that is long-lasting and which can be cost-efficiently evolved and migrated to use new technologies. Practical challenges that require significant research in software sustainability include: (i) organisations losing control over software; (ii) difficulty in coping with modern software’s continuous and unpredictable changes; (iii) dependency of software sustainability on factors that are not purely technical; (iv) enabling “write code once and run it anywhere” paradigm.

As software complexity increases, it becomes more difficult for organisations to understand which parts of their software are worth maintaining and which need to be redeveloped from scratch. Therefore, we need methods to reduce the complexity of the software that is worth maintaining, and extracting domain knowledge from existing systems as part of the redevelopment effort. This also relates to our inability to monitor and predict when software quality is degrading, and to accurately estimate the costs of repairing it. Consequently, sustainability of the software is often an afterthought. This needs to be flipped around – i.e. we need to design “future-proof” software that can be changed efficiently and effectively, or at least platforms for running software need to either enable this or force such way of thinking.

As (embedded) software systems evolve towards distributed computing, SoS and microservice-based architectural paradigms, it becomes even more important to tackle the challenges of integration at the higher abstraction levels and in a systematic way. Especially when SoS or IoT is involved, it is important to be able to separate the concerns over the subsystems.

The ability of updating systems in the field in a way that safety of the updated systems as well as security of the deployment process is maintained will be instrumental for market success of future ECPS. Edge-to-cloud continuum represents an opportunity to create software engineering approaches and engineer platforms that together enable deployment and execution of the same code anywhere on this computing continuum.

The ability of keeping track of system parameters like interface contracts and composability requires a framework to manage these parameters over the lifetime. This will enable the owner of the system to identify at any time how the system is composed and with what functionality.

Instead of focusing just on the efficiency of embedded software engineering, we already see that the field is evolving into direction of cyber physical systems (cf. Chapter 2.3 Architecture and Design: Methods and Tools), and software is one element of engineering.

Many software maintenance problems are not actually technical but people problems. There are several socio-technical aspects that can help, or hinder, software change. We need to be able to organise the development teams (e.g. groups, open source communities) in such a way that it embraces change and facilitates maintenance and evolution, not only immediately after the deployment of the software but for any moment in software lifecycle, for the decades that follow, to ensure continuity. We need platforms that are able to run code created for different deployment infrastructure, without manual configuration.

The expected outcome is that we are able to keep embedded systems relevant and sustainable across their complete lifecycle, and to maintain, update and upgrade embedded systems in a safe and secure, yet cost-effective way.

The key focus areas identified for this challenge include the following.

• Rejuvenation of systems:
  • Software legacy and software rejuvenation to remove technical debt (e.g. software understanding and conformance checking, automatic redesign and transformation).
  • Continuous platform-agnostic integration, deployment and migration.
  • End-of-life and evolving off-the-shelve/open source (hardware/software).
• Managing complexity over time:
  • Interplay between legacy software and new development approaches.
  • Vulnerability of connected systems.
  • Continuous certification of updates in the field (reduce throughput time).
  • Intelligent Diagnostics of systems in the field (e.g. guided root cause analysis)
• Managing configurations over time:
  • Enable tracking system configurations over time.
  • Create a framework to manage properties like composability and system orchestration.
• Evolvability of embedded software:
  • Technology, including automation of engineering and the application of integration and orchestration platforms, for keeping systems maintainable, adaptable and sustainable considering embedded constraints with respect to resources, timing and cost.
  • Embedded software architectures to enable SoS.

For various reasons – including privacy, energy efficiency, latency and embedded intelligence – processing is moving towards edge computing, and the software stacks of embedded systems need to support more and more analysis of data captured by the local sensors and to perform AI-related tasks. As detailed in the Chapter "Edge Computing and Embedded Artificial Intelligence", non-functional constraints of embedded systems, such as timing, energy consumption, low memory and computing footprint, being tamperproof, etc., need to be taken into account compared to software with similar functionalities when migrating these from cloud to edge. Furthermore, Quality, Reliability, Safety and Security Chapter states that key quality properties when embedding of AI components in digitalized ubiquitous systems are determinism, understanding of nominal and degraded behaviours of the system, their certification and qualification, and clear liability and responsibility chains in the case of accidents. When engineering software that contains AI-based solutions, it is important to understand the challenges that such solutions introduce. AI contributes to challenges of embedded software, but itself it does not define them exclusively, as quality properties of embedded software depend on integration of AI-based components with other software components.

For efficiency reasons, very intensive computing tasks (such as those based on deep neural networks, DNNs) are being carried out by various accelerators embedded in systems on a chip (SoCs). Although the “learning” phase of a DNN is still mainly done on big servers using graphics processing units (GPUs), local adaptation is moving to edge devices. Alternative approaches, such as federated learning, allow for several edge devices to collaborate in a more global learning task. Therefore, the need for computing and storage is ever-increasing, and is reliant on efficient software support.

The “inference” phase (i.e. the use after learning) is also requiring more and more resources because neural networks are growing in complexity exponentially. Once carried out in embedded GPUs, this phase is now increasingly performed on dedicated accelerators. Most middle and high-end smartphones have SoC embedding one of several AI accelerators – for example, the Nvidia Jetson Xavier NX is composed of six Arm central processing units (CPUs), two inference accelerators, 48 tensor cores and 384 Cuda cores. Obtaining the best of the heterogeneous hardware is a challenge for the software, and the developers should not have to be concerned about where the various parts of their application are running.

Once developed (on servers), a neural network has to be tuned for its embedded target by pruning the network topology using less precision for operations (from floating point down to 1-bit coding) while preserving accuracy. This was not a concern for the “big” AI development environment providers (e.g., Tensorflow, PyTorch, Caffe2, Cognitive Toolkit) until recently. This has led to the development of environments designed to optimise neural networks for embedded architectures51: to move towards the Edge.

Most of the time the learning is done on the cloud. For some applications/domains, making a live update of the DNN characteristics is a sought-after feature, including all the risks of security, interception. Imagine the consequences of tampering with the DNN used for a self-driving car! A side-effect of DNN is that intellectual property is not in a code or algorithm, but rather lies in the network topology and its weights, and therefore needs to be protected.

European semiconductor providers lead a consolidated market of microcontroller and low-end microprocessor for embedded systems, but are increasing the performance of their hardware, mainly driven by the automotive market and the increasing demand for more performing AI for advanced driver-assistance systems (ADAS) and self- driving vehicles. They are also moving towards greater heterogeneity by adding specialised accelerators. On top of this, Quality, Reliability, Safety and Security Chapter lists personalization of mass products and resilience to cyber-attacks, as the key advantage and the challenge characterizing future products. Embedded software needs to consider these and find methods and tools to manage their effects on quality properties of software that integrates them. Also, embedded software engineering will need to ensure interoperability between AI-based solutions and non-AI parts.

In this context, there is a need to provide a programming environment and libraries for the software developers. A good example here is the interchange format ONNX, an encryption format for protection against tampering or reverse engineering that could become the foundation of a European standard. Beside this, we also need efficient libraries for signal/image processing for feeding data and learning into the neural network, abstracting from the different hardware architectures. These solutions are required to be integrated and embedded in ECPS, along with significant effort into research and innovation in embedded software.

The key focus areas identified for this challenge include the following.

• Federated and distributed learning:
  • Create federated learning at the edge in heterogeneous distributed systems (analysis, modelling and information gathering based on local available information).
  • Federated intelligence at the edge (provide context information and dependability based on federated knowledge).
• Embedded Intelligence:
  • Create a software AI framework to enable reflecting and acting on the systems own state.
  • Dynamic adaption of systems when environment parameters and sensors like IoT devices are changing.
• Data streaming in constraint environments:
  • Feed streaming data into low-latency analysis and knowledge generation (using context data to generate relevant context information).
• Embedding AI accelerators:
  • Accelerators and hardware/software co-design to speed up analysis and learning (e.g. patter analysis, detection of moves (2D and 3D) and trends, lighting conditions, shadows).
  • Actual usage-based learning applied to accelerators and hardware/software co-design (automatic adaptation of parameters, adaptation of dispatch strategies, or use for new accelerators for future system upgrades).

The complete power demand in the whole ICT market currently accounts from 5% to 9% of the global power consumption52. The ICT electricity demand is rapidly increasing and it could go up to nearly 20% in 2030. Compared to estimated power consumption of future large data centres, embedded devices may seem to be a minor problem. However, when the devices are powered by batteries they still have a significant environmental impact. Energy efficient embedded devices produce less hazardous waste and last longer time without need to be replaced.

The growing demand for ultra-low power electronic systems has motivated research into device technology and hardware design techniques. Experimental studies have proven that the hardware innovations for power reduction can be fully exploited only with proper design of the upper layer software. The same applies to software power and energy modelling and analysis: the first step towards the energy reduction is complex due to the inter- and intra-dependencies of processors, operating systems, application software, programming languages and compilers. Software design and implementation should be viewed from a system energy conservation angle rather than as an isolated process.

For sustainability, it is critical to understand quality properties of software. These include in the first place power consumption, and then other related properties (performance, safety, security, and engineering-related effort) that we can observe in the context of outdated or inadequate software solutions and indicators of defected hardware. Power reduction strategies are mainly focusing on processing, storage, communication, and sometimes on other (less intelligent) equipment.

For the future embedded software developers, it is crucial to keep in touch with software development methodologies focused to sustainability, such as green computing movement or sustainable programming techniques. In the domain of embedded software, examples include the remaining useful life of the device estimation, the network traffic and latency time optimization, the process scheduling optimization or energy efficient workload distribution.

The concept of sustainability is based on three main principles: the ecological, the economical and the social. The ideal environmentally sustainable (or green) software in general requires as little hardware as possible, it is efficient in the power consumption, and its usage leads to minimal waste production. An embedded software designed to be adaptable for future requirements without need to be replaced by a completely new product is an example of environmentally, economically, and socially sustainable software.

To reach the sustainability goal, the embedded software design shall focus also on energy-efficient design methodologies and tools, energy efficient and sustainable techniques for embedded software and systems production and to development of energy aware applications and frameworks for the IoT, wearable computing or smart solutions or other application domains.

It is evident that energy/power management has to be analysed with reference to the context, underlying hardware and overall system functionalities. The coordinated and concentrated efforts of a system architect, hardware architect and software architect should help introduce energy-efficient systems (cf. Chapter 2.3, Architecture and Design: Methods and Tools). The tight interplay between energy-oriented hardware, energy-aware and resource-aware software calls for innovative structural, functional and mathematical models for analysis, design and run-time. Model-based software engineering practices, supported by appropriate tools, will definitely accelerate the development of modern complex systems operating under severe energy constraints. It is crucial to notice the relationship between power management and other quality properties of software systems (e.g., under certain circumstances it is adequate to reduce the functionality of software systems by disabling certain features, which results in significant power savings). From a complementary perspective, when software is aware of the available hardware and energy resources, it enables power consumption optimisation and energy saving, being able to configure the hardware resources, to activate/deactivate specific hardware components, increase/decrease the CPU frequency according to the processing requirements, partition, schedule and distribute tasks.

Therefore, in order to enable and support sustainability through software, software solutions need to be reconfigurable in the means of their quality. There have to exist strategies for HW/SW co-design and accelerators to enable such configurations. For this to be possible, software systems need to be accompanied with models of their quality properties and their behaviour, including the relationship between power consumption and other high level quality properties. This will enable balancing mechanisms between local and remote computations to reduce communication and processing energy.

Models (digital twins) should be aware of energy use, energy sources and the sustainability of the different sources. An example of this in SoS are solar cells that give different amounts of energy dependent on daytime and weather conditions.

The following key focus areas have been identified for this challenge:

• Resource-aware software engineering.
• Tools and techniques enabling the energy-efficient and sustainable embedded software design.
• Development of energy-aware and sustainable frameworks and libraries for the main embedded software application areas (e.g. IoT, Smart Industry, Wearables).
• Management of computation power on embedded hardware:
  • Management of energy awareness of embedded hardware, embedded software with respect to, amongst others, embedded high-performance computing (HPC). Composable efficient abstractions that drive sustainable solutions while optimising performance
  • Enabling technologies for the second life of (legacy) cyber-physical systems.
  • Establish relationships between power consumption and other quality properties of software systems, including engineering effort (especially in cases of computing-demanding simulations).
  • Digital twins can contribute in management quality properties of software systems with goal of reducing power consumption, as the major contributing factor to green deal, enabling sustainability.

Two emerging challenges for reliability and trust in ECPS relate to computing architectures and the dynamic environment in which ECPS exist. The first challenge is closely related to the end of Dennard scaling53. In the current computing era, concurrent execution of software tasks is the main driving force behind the performance of processors, leading to rise of multicore and manycore computing architectures. As the number of transistors on a chip continues to increase (Moore’s law is still alive), industry has turned to a heavier coupling of software with adequate computing hardware, leading to heterogeneous architectures. The reasons for this coupling are the effects of dark silicon54 and better performance-to-power ratio of heterogeneous hardware with computing units specialised for specific tasks. The main challenges for using concurrent computing systems in embedded systems remain: (i) hard-to-predict, worst-case execution time; and (ii) testing of concurrent software against concurrency bugs55.

The second challenge relates to the dynamic environment in which ECPS execute. On the level of systems and SoS, architectural trends point towards platform-based designs – i.e. applications that are built on top of existing (integration and/or middleware) platforms. Providing a standardised “programming interface” but supporting a number of constituent subsystems that is not necessarily known at design time, and embedding reliability and trust into such designs, is a challenge that can be solved only for very specialised cases. The fact that such platforms – at least on a SoS level – are often distributed further increases this challenge.

On the level of systems composed from embedded devices, the most important topics are the safety, security, and privacy of sensitive data. Security challenges involve: (i) security of communication protocols between embedded nodes, and the security aspects on the lower abstra ction layers; (ii) security vulnerabilities introduced by a compiler56 or reliance on third-party software modules; and (iii) hardware-related security issues57. It is necessary to observe security, privacy and reliability as quality properties of systems, and to resolve these issues on a higher abstraction level by design58, supported by appropriate engineering processes including verification.

European industry today relies on developed frameworks that facilitate production of highly complex embedded systems (for example, AUTOSAR in the automotive industry).

The ambition here is to reach a point where such software system platforms are mature and available to a wider audience. These platforms need to enable faster harvesting of hardware computing architectures that already exist and provide abstractions enabling innovators and start-ups to build new products quickly on top of them. For established businesses, these platforms need to enable shorter development cycles while ensuring their reliability and providing means for verification & validation of complex systems. The purpose of building on top of these platforms is ensuring, by default, a certain degree of trust for resulting products. This especially relates to new concurrent computing platforms, which hold promise of great performance with optimised power consumption.

Besides frameworks and platforms that enable easy and quick development of future products, the key enabler of embedded software systems is their interoperability and openess. In this regard, the goal is to develop and make available to a wider audience, software libraries, software frameworks and reference architectures that enable interoperability and integration of products developed on distributed computing architectures. They also need to ensure, by design, the potential for monitoring, verification, testing and auto-recovery of embedded systems. One of the emerging trends to help achieving this is the use of digital twins. Digital twins are particularly suitable for the verification of safety-critical software systems that operate in dynamic environments. However, development of digital twins remains an expensive and complex process, which has to be improved and integrated as part of the standard engineering process processes (see challenge 2 in Chapter 2.3).

We envision an open marketplace for software frameworks, middleware, and digital twins that represents a backbone for the future development of products. While such artefacts need to exploit the existing software stacks and hardware, they also need to support correct and high-quality software by design. Special attention is required for Digital Twin simulations of IoT devices to ensure reliability and trust in operating in real life.

Focus areas of this challenge are related to quality aspects of software. For targets such as new computing architectures and platforms, it is crucial to provide methodologies for development and testing, as well as for the team development of such software. These methodologies need to take into account the properties, potentials and limitations of such target systems, and support developers in designing, analysing and testing their implementations. As it is fair to expect that not all parts of software will be available for testing at the same time, it is necessary to replace some of the concurrently executing models using simulation technologies. Finally, these achievements need to be provided as commonly available software modules that facilitate the development and testing of concurrent software.

The next focus area is testing of systems against unexpected uses, which mainly occurs in systems with a dynamic execution environment. It is important here to focus on testing of self-adapting systems where one of the predominant tools is the simulation approach, and more recently the use of digital twins.

However, all these techniques are not very helpful if the systems are not secure and reliable by design. Therefore, it is necessary to investigate platforms towards reliability, security and privacy, with the following challenges:

• Reliable software on new hardware including edge, fog and cloud processing: (co) verification of distributed, also heterogenous systems.
• Verification and validation of ML models.
• Robustness against unexpected uses:
  • Trustworthy, secure, safe, privacy-aware.
  • Validating self-adapting systems for example through simulation.
• Security and privacy as a service:
  • To become part of the software architecture.
  • Means and techniques for continuous system monitoring and self-monitoring.