1 Foundational Technology Layers

It is fair to assume that most future software applications will be developed to function as part of a certain platform, and not as stand-alone 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 SoS¹⁰, 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 due to the wide range of hardware architectures and platforms, each with its own unique characteristics. Continuous integration must account for this diversity, requiring cross-compilation and testing on various target devices. Continuous delivery must deal with the fact that the products into which the new software modules have to be delivered 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 a reference 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 micro-services 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 such as CI/CD will be crucial to adapt. The primary DevOps methodology needs to be adjusted for the ECPS. For example, CI pipelines will enable toolchain selection configuration for cross-compiling, or they will include real-time testing and validation, which can be more challenging to automate and verify. Integrating automated tests for hardware interactions can be complex and require specialized hardware-in-the-loop (HIL) testing setups.

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 at the platform 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 validation and verification processes for new features as they are being introduced into the system. This might need the use of AI in the validation and verification process. At this level, it is also necessary to use software system architectures in the automation of verification and other engineering practices, to manage the complexity that arises from such integration efforts (also see Major Challenge 3 below).

Artificial Intelligence and Machine Learning

Progress in AI keeps being fast-paced. While typical ECPS-needs such as Computer Vision are dominated by AI since quite some time, recent progress in Large Language Models (LLMs) opened the door to serious AI-assisted engineering tools. Hence, AI is on the way to becoming an important tool for the engineering of Embedded Software, while being an essential part of Embedded Software at the same time.

AI in Embedded Software. Simply speaking, AI lets us implement functions we don’t need to understand as they are learned automatically. This has advantages and drawbacks. We take advantage of this property in tiny sensors, where AI (e.g. TinyML) automatically approximates a mapping of property changes of some material to a measurement value, in prediction, control or virtual sensing, where AI has learned to interpret time series, images, or other forms of data, and many other tasks, including detection and tracking of objects. AI functions can also serve as (automated) abstractions. With this versatility, wide-spread adoption, and a potential non-understanding of what was learned, come challenges like fitting the AI functionality to the available resources (cf. RISC-V with research on AI accelerators), testability / explainability / trustworthiness / integration in safety critical applications, real-time performance, updateability / continuous learning / maintainability, and more. In general, AI in Embedded Software faces all the same challenges standard Embedded Software has, some in a more demanding form of course. For example, using sub-symbolic AI in a safety-critical context is without a clear-cut solution regarding the trustworthiness issues. To compensate for these, extensive monitoring, and the implementation of certain architectures (e.g. Simplex) might be necessary. This shows that relying on AI in a system will have a big impact on the system design. Relying on AI will also have a massive impact on verification planning and software engineering as, e.g. proper training and validation data sets need to be provided.

AI for Embedded Software engineering. Software engineering is the discipline of building software in a proper way. AI can help with that, and AI functionality has been explored in tools for software engineering for some time. However, up to now AI-algorithms were mostly used in tools for verification (automated test case generation, checking) and less so in others. Recent developments in LLMs demonstrate the huge potential for using AI in areas like model or code generation from natural language, refactoring or “rejuvenation” of legacy software, porting software while preserving investment, or automatically adapting software to different settings/platforms. Like before, the major challenge is that there is no guarantee on the correctness or fit-for-purpose on the output of these LLMs, which is a major research opportunity at the same time. In future, AI is likely to replace many of the software-coding activities done by engineers today. Also, domain specific models will speed-up software design & generation by a considerable amount, and AI will support engineers in system understanding and in mastering complexity.

Summing up, AI hasn’t yet shown its full potential for the use in and around Embedded Software – there are still many challenges left as demanding research topics. However, based on the current state-of-art and results, it is clear that AI will be a core part of future Embedded Software and ECPS.

The RISC-V instruction set architecture (ISA) is the fifth version of the Berkeley ISA that has seen exponential commercial and academic adoption in the last 10 years thanks to its open-source nature, as well as its modularity, extendibility, and simple architecture. Many commercial users adopt RISC-V in their System-On-Chips, from both open-source repositories (where the Register-Transfer-Level description of the RISC-V CPU is published), or from closed-source IP vendors. The increase in silicon devices together with the need for digital sovereignty caused many national and international organizations to take action, and RISC-V is a main actor of this revolution. For example, the European Commission¹¹ is building an open-source ecosystem to expand its innovation on RISC-V to compete with existing commercial alternatives, covering hardware design and system-on-chips, all the way to electronic design automation tools and the full software stack. In this scenario, OpenHW Group¹² and the Eclipse Foundation¹³ play a key role in developing open-source, high-quality, silicon-proven RISC-V IPs under a permissive license. Both the not-for-profit foundations are driven by their members, who invested in RISC-V and open-source-based System-On-Chip. The modularity and extendability of the RISC-V ISA allow users to design their own architecture to meet the ultra-low-power and energy-efficient edge-computing devices constraints, as well as high-performance server machines requirements. For example, the “RVV RISC-V Vector” ISA extension allows to process multiple data concurrently, or custom extensions for security to encrypt data more efficiently. For this reason, it is crucial to have a holistic software stack to cope with the wide range of applications, taking into account the deployment of efficient applications leveraging the different ISA extensions and computer architectures.

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.

  • Enabling reliable and safe continuous SW delivery to already working devices.

• 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, vehicles 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 the fact that most of these systems are 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 are even required for the ‘continuous development and integration’ paradigm.

Embedded software also must be maintained and adapted over time, to fit new product variants or even new product generations and enable updateability of existing 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. Over-The-Air solutions become key enablers to this regard, especially for distributed systems, and they will have to cover the different paces at which HW and SW evolve, determining when updates become necessary. Edge-to-cloud continuum represents an opportunity to create software engineering approaches and engineering 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. To this regard, the onboarding process of the constituent systems becomes a crucial phase to maintain the desired levels of security and safety: SoS integration platforms should provide solid onboarding procedures that guarantee no compromised HW and SW become part of the SoS. The adoption of block chain technologies, digital contracts and security certificates, etc. could prevent similar situations, which could impact not only the SoS during operation but also the entire supply chain associated to it. The onboarding phase should also be automated to increase security levels and ensure scalability.

Instead of focusing just on the efficiency of embedded software engineering, we already see that the field is evolving into the 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 the software lifecycle, for the decades that follow, to ensure continuity. We need platforms that are able to run code created for different deployment infrastructures, 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: new functionalities enabling and facilitating secure and automated onboarding processes, OTA software maintenance (see also the SoS chapter), ….

  • Embedded software architectures to enable SoS.

For various reasons – including privacy, energy efficiency, latency and the increasing necessity of smart data analytics on site – processing and artificial intelligence are moving towards the edge (edge computing), forcing the software stacks of embedded systems to coherently evolve supporting these new computing paradigms. 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 the cloud to the edge. Furthermore, the 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 contains AI-based solutions, it is important to understand the challenges that such solutions introduce. Indeed, AI contributes to address challenges of embedded software, but it does not define them exclusively itself, 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. Also, LLMs are experiencing a similar evolution towards the edge. 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 SoCs embedding one of several AI accelerators, as well as Mx Apple processors family for laptops, tablets and future wearables – 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 architectures¹⁵ 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 or LLM characteristics is a sought-after feature, including all the risks of security, interception. Imagine the consequences of tampering with the DNN or LLM used for a self-driving car! A side-effect of DNN or LLM 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 companies lead a consolidated market of microcontrollers and low-end microprocessors 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. With edge computing and embedded AI this trend has extended to other vertical domains that are key for Europe. European semiconductor companies 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 consumption¹⁶. 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 without the need for replacement.

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. Partitioning hardware enables smart power-up/power-down strategies. Together with support through resource-aware algorithms, this could lead to significant energy savings. 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 on sustainability, such as green computing movement, resource-aware computing and, more generally, sustainable programming techniques. In the domain of embedded software, examples include the estimation of the remaining useful life of the device, the network traffic and latency time optimization, the process scheduling optimization or energy efficient workload distribution, the management of HW and SW resources oriented to energy saving, the correct use of software abstraction, etc.

The concept of sustainability is based on three main pillars: ecological, economic and social. The ideal environmentally sustainable (or green) software in general requires as little hardware as possible, it is efficient in power consumption, and its usage leads to minimal waste production. Embedded software designed to be adaptable for future requirements without the 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 the development of energy- and resource-aware applications and frameworks for embedded systems, edge computing, embedded intelligence and their applications.

It is evident that energy/power management has to be analysed with reference to the context, to the underlying hardware resources and the overall system functionalities. The coordinated and concentrated efforts of a system architect, hardware architect and software architect should help to 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 resources and their energy profile, 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 must exist strategies for HW/SW co-design and accelerators to enable such configurations, and the entire integrated development environment should facilitate a rational use of abstraction (abstraction simplifies software development but increases the energy consumption) and supports HW and SW resources usage optimisation from the energy perspective directly from the programming language and through the compiler, linker, assembler, etc. 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 also enable balancing mechanisms between local and remote computations to reduce communication and processing energy consumption.

Models (digital twins) should be aware of energy use, energy sources, HW and SW resources and their sustainability profile. An example of this in SoS are solar cells that give different amounts of energy dependent on time of day 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 embedded software key application areas (e.g. IoT, Smart Industry, wearables, etc.).

• 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 resource-aware computing.

  • 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 support the management of quality properties of software with the goal of reducing power consumption, as the major contributing factor to the 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 scaling¹⁷. In the current computing era, concurrent execution of software tasks is the main driving force behind the performance of processors, leading to the 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 silicon¹⁸ 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 bugs¹⁹.

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 abstraction layers; (ii) security vulnerabilities introduced by a compiler²⁰ or reliance on third-party software modules; and (iii) hardware-related security issues²¹. 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 design²², supported by appropriate engineering processes including verification (see Chapters 2.3 and 2.4).

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. Recent developments in programming languages - such as Rust - look promising, as they aim to solve some of these inherited problems by default, based on available programming language constructs.

Besides frameworks and platforms that enable easy and quick development of future products, the key enabler of embedded software systems is their interoperability and openness. In this regard, the goal is to develop and make software libraries, software frameworks and reference architectures which need to ensure, by design, the potential for monitoring, verifying, testing and auto-recovering of embedded systems. That enables interoperability and integration of products developed on distributed computing architectures available to a wider audience. 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 processes (see Major 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.

New concepts for programming languages, such as Rust, by their default design resolve some of the listed issues in developing computing architectures. For example, one of the main goals of Rust is handling concurrent and parallel programming in a safe and efficient way²³. New concepts in the area of programming languages need to balance between several factors. From one side, new programming languages need to offer higher productivity to engineers. Programming languages need to enable more efficient collaboration between engineers by being more suitable to higher level architectural thinking that prioritise decoupled development of individual software components. Furthermore, traditional programming languages, such as C and C++, are challenging for static analysis due to undecidability of their statements²⁴ and in general have huge test space making them susceptible to security issues. Finally, new languages need to solve by design complex problems in programming, such as concurrency and parallelism. On the other hand, it is necessary to minimize overhead of abstractions in new programming languages (performance²⁵ and energy^{26 27} overhead). Besides creating such languages or extending the existing ones with news features, it is still necessary to provide methodologies that will guide industry to migrate their code bases to new programming constructs, or at least ensure co-existence and interaction between new and old code bases. With the introduction of AI into software engineering, we are looking for programming languages that will facilitate a new AI-assisted²⁸ software development approach. That means programming languages that engineers can use to easily and as deterministically as possible express their intentions, while those languages are suitable for AI to enable code generation and automatization of validation, verification, and testing activities. Furthermore, we hope to have in the future such programming languages that facilitate, with the assistance from AI, analysis of quality properties of whole software stacks (e.g., WCET analysis, safety analysis²⁹).

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.

Hardware virtualisation provides efficient abstraction from the physical hardware, thus allowing to decouple software engineering lifecycles from the underlying hardware. This is usually implemented either by full-scale hypervisors like VMware and KVM, or via containerisation as combination with the hosting operating system, e.g. Docker and Kubernetes. It enhances efficiency through resource isolation and allocation, and eases deployment by offering lightweight, portable, and scalable software packaging. Additionally, hardware-assisted virtualisation extensions such as Intel VT-x and AMD-V have improved performance and security by offloading virtualisation tasks to the hardware.

Hardware virtualisation is expected to offer numerous benefits, including increased flexibility, portability, and security for safety-critical and non-safety-critical applications.

• Standardized Abstraction Models for hardware components to enable cross-platform compatibility, fostering ease of development and integration.

• Timing Models: Developing reliable timing models to predict and verify real-time behaviour accurately.

• Unified APIs for different hardware components to promote interoperability.

• Performant run-time environments supporting shared memory access control, leveraging hypervisor technologies like XEN and KVM, as well as Bytecode/WebAssembly technologies.

• Virtualisation of communication (Virtual Networks) supporting Quality of Service (QoS) mechanisms to guarantee real-time communication in mixed-criticality environments.

• Hardware Abstraction for Sensors and Actuators, to achieve their interchangeability.

To realize the potential of hardware virtualisation, research and development will focus on three aspects.

• Standard development methods and frameworks for the development of hardware abstractions, integrated with existing tools.

• Verification and validation frameworks, supported by automation, which allow for the validation of applications within virtualisation, as well as the validation of specific target systems, to confirm performance and timeliness.

• Run-time environments for safety-critical applications.

To cover these aspects, it is necessary to understand what they aim to achieve in software system engineering terms. To facilitate software development in virtual environments, the most common requirement in industry is to enable functional testing on virtual hardware. Such testing must provide fast execution feedback suitable for continuous engineering. Currently, there already exist techniques that try to achieve this³⁰. What we also need is higher integration of such virtual platforms in common engineering development methodologies (e.g., Agile). To achieve other goals from the list above (e.g., performance and temporal properties evaluation), it is necessary to have more complex, detailed models of virtual hardware. Examples of such models currently exist³¹, but are extremely slow to execute. Besides integration of virtual platforms into existing methodologies and making execution of these models faster, it is necessary to observe the challenge around this effort in a wider scope. Development of virtual prototypes is not easy and often requires significant effort and investment. Moreover, management of platforms on which these prototypes execute is also a complex task (e.g. using BlueChi³²). Finally, management of models, their variations, and integration activities with software repositories and test suites is challenging and time consuming. Therefore, we need approaches that facilitate faster development of virtual platforms, infrastructure around using them in software engineering, and management of both the models and the infrastructure. With these efforts, we hope to migrate a larger part of the development of embedded software systems to the cloud, facilitating collaboration and enabling higher engineering efficiency.