A Framework for Communication–Compute–Control Co-Design in Cyber–Physical Systems

Abstract

Cyber–physical systems are created at the intersection of physical processes, networking, and computation. For applications developed to implement cyber–physical interactions, in the face of limited resources, an optimization of efficiency needs to be handled across all entities—communication, computing, and control. This gives rise to the emerging area of “co-design” that addresses the challenge of designing applications or systems at the intersection of control, communication, and compute when these domains can and should no longer be considered to be fully independent. In this article a co-design framework is presented that provides a structured way of addressing the co-design problem. Different co-design degrees are specified that group application design approaches according to their needs on criticality/dependability and relate these to the knowledge, insights, and required interactions with the communication and computation infrastructure. The applicability of the framework is illustrated for the example of autonomous mobile robots, showing how different co-design degrees exploit the relationships and permit the identification of technical solutions that achieve improved resource efficiency, increased robustness, and improved performance compared to traditional application design approaches. The framework is of relevance both for concrete near-term application implementation design as well as more futuristic concept development.

1. Introduction

The ongoing development towards a reality, where physical objects are connected and digitally engaged to execute on their assigned activities and processes, has established the term cyber–physical systems (CPSs). Cyber–physical systems are created at the intersection of physical processes, networking, and computation. They integrate components of various kind whose main purpose is to control a physical process and, through feedback, adapt themselves to new conditions in real time [1]. Whether it is in the consumer world (e.g., mixed reality), or the industrial world (e.g., autonomous mobility), or both (e.g., massive digital twins), cyber–physical interactions are becoming an integral part of our lives, and this development is expected to grow [2]. Figure 1 illustrates the cyber–physical continuum. In the cyber–physical continuum, the physical and digital world have merged. It is now possible to move freely between the connected physical world of senses, actions and experiences, and its programmable digital representation. This is achieved by countless sensors that are embedded in the physical world. These send data to update the digital representation of the physical world in real time. At the same time, actuators in the real world carry out functions that are programmed in the digital representation. Observations, but also tracing back and analyzing the past are key elements to act in real-time but also to simulate, predict, and program the future. As an example, a robot operating in the physical world may be updated, re-designed, optimized, etc., iteratively by moving freely between observations and operations in the digital reality while combining this information with testing and predicting operations in the digital reality.

For applications developed to implement such types of control, access to and interaction with computation and communication are expected to play an increasingly important role [3]. The vision is that digitalization will be embraced across industries and society at large creating an increasingly digitalized, programmable, and intelligent world embracing the cyber–physical continuum [2].

Future innovative applications developed for cyber–physical systems are envisioned to take smarter decisions than today’s applications by, e.g., making heavy use of Machine Learning (ML) and Artificial Intelligence (AI), as well as adding the possibility to execute some/all parts of their functionality from a cloud compute environment [4]. These interactions require the control applications to have a detailed understanding of their requirements and technical needs when it comes to communication and computing and to make corresponding requests for communication and computational resources.

All of the above calls for a shift towards seamless interworking among communication, computing, and control entities within a cyber–physical system, enabled by the exchange of capabilities and demands among them. Such interworking is essential to meet stringent requirements on availability, latency, and reliability for application use cases, surpassing just ‘best effort’ standards. Furthermore, in the face of limited resources, all entities—communication, computing, and control—must be optimized for efficiency. With the ever-increasing number of applications entering the cyber–physical continuum, developing an improved understanding of how to optimize efficiency across different domains under the constraint of limited resources, therefore, becomes increasingly important. A key observation in this regard is that compared to previous approaches, in order to achieve higher performance, the domains of communication, compute, and control can no longer be considered independently [3,5,6]. Therefore, a new approach of “co-designing” cyber–physical systems across the domains of communication, compute and control is starting to take shape for which better performance, scalability, and resilience are expected to be feasible. Three different actors are part of the co-design: Communication platform(s) (e.g., networks), computing platform(s) (e.g., edge, cloud, fog), as well as the control domain (e.g., application developers). Each of these actors plays a role in the co-design. However, the ambition of co-design is not to solve the efficiency optimization problem for all domains with a joint design in a centralized way. Instead, the approach is to address the optimization problem by exposing and exploiting insights from the different domains.

This article makes an important contribution to the area of co-design by suggesting a co-design framework that allows for a structured approach towards the adoption of co-design principles.

2. Research Aims and Objectives

In this section the definition of co-design, its approach and ambition as well as more details on the contributions of this article to this area are outlined.

2.1. Definition of Communication–Compute–Control Co-Design and Its Ambition

Communication–Compute–Control (3C) co-design is an application or system design method that understands and makes use of the relations among (wireless) communication, (cloud) compute, and (control) applications to enhance application and/or overall system performance. The objective of the co-design approach is to exploit the relationships to find technical solutions that achieve improved resource efficiency, increased robustness, and advanced performance compared to traditional approaches. Another ambition of the co-design methodology is to potentially relax requirements on each of the 3Cs components compared to independent design, thereby also enabling applications that would otherwise (1) not be feasible to implement due to too stringent requirements or (2) require a very costly infrastructure. Figure 2 and Figure 3 illustrate the traditional approach and the ambition with the co-design approach. Unlike the simple publish–subscribe communication paradigm of information exchange [7], in advanced co-design approaches, insights from the compute and communication entities are also shared in response to the requested service.

2.2. Contributions of This Article

The key contribution of this article is the development and description of a framework for 3Cs co-design, which takes a structured approach towards the adoption of the co-design principles. By defining different “degrees” of co-design, it is shown that a co-design approach can be applied at different levels, where the level depends on the requirements of the application. In particular, it is shown how the challenge of co-design can be broken down into meaningful steps that still allow for exploiting the advantage of shared knowledge and insights. By exemplifying the framework with an industrial use case, the benefits and challenges of the different co-design degrees are illustrated. The identification of key building blocks and tradeoffs allows for a better understanding of ongoing and required next steps for research and development.

The framework presented in this article is formulated on a conceptual level for a general type of application. Here, “application” can be considered as an abstract function that realizes a set of tasks for a given use case. The focus is on possible interactions of this abstract application domain with the network and compute domains to realize the wanted outcome.

2.3. Structure of the Article

This article is structured as follows: Section 1 and Section 2 present the topic and provide an introduction, including details on the scope and contributions of the work. Section 3 outlines the state of the art, observed trends, as well as related and prior work. Section 4 introduces the framework of co-design developed in this work, together with an example that illustrates the applicability of the framework. Section 5 outlines the building blocks of co-design, and Section 6 discusses tradeoffs, important considerations, as well as possible next steps. In Section 7, the work is summarized and concluded.

3. State of the Art, Observed Trends in Industry and Prior Work

In the following Section, the state of the art in industry together with ongoing trends are described that highlight the dependencies of communication, compute, and control and motivate the need for studying 3Cs co-design. Furthermore, prior and related work are described.

3.1. State of the Art and Trends in Industry

3.1.1. Trend Towards Wireless Communication for CPSs

While most of the control systems of today continue to rely on wired communication, there is a growing inclination towards adapting wireless technology in control systems. For instances wireless communication is becoming an integral part of modern smart manufacturing [4]. Examples include, for instance, (1) remote wireless control of devices and heavy machinery [8] that unlocks the potential for advanced services where cables are not able to reach, or (2) wireless condition monitoring that enables services, e.g., for moving parts [9]. Generally, compared to connecting devices and machines with cables, wireless connectivity allows for a higher degree of flexibility and can significantly reduce setup and maintenance time and costs [10]. Non-critical applications can easily be connected using wireless technology. But real-time control systems that impose very strict requirements towards the wireless network are a challenge for wireless connectivity solutions since wireless channels are naturally subject to stochastic variations. Numerous efforts have been made to design wireless communication systems that closely match the performance of wired systems in terms of data rate, latency, reliability, etc. [11], in order to support critical real-time applications. However, the past ten years have shown that it is only if the wireless link performs just like a wired link (e.g., negligible delay, jitter, and packet loss), the wireless link could attempt a “simple replacement” of communication cables with wireless links in control applications without making any changes to the application. The reason for this is that applications that are designed to work only over wired connections, typically assume close to ideal network characteristics and lack the robustness or flexibility to adjust to statistical variances resulting from connectivity [12]. Wireless solutions that perform just like a wired link, however, require extensive network resources, which becomes impractical, costly, or even infeasible in several deployments [13]. While this may indicate that wireless communication may be less suitable for critical control systems, there is on the contrary, a growing interest in considering wireless communications also for these. One of the key reasons comes from the trend towards cloudification and cloud-native application design, as described in the following subsection. Another key reason comes from the insight from the control perspective that the strictness in requirements when it comes to the determinism of control systems, is to a significant extent, an implementation choice during application design. Modifying the implementation of control systems can affect/reduce the degree of determinism [3]. Moreover, the strictness of requirements may vary, e.g., depending on the scenario, over time, etc. This flexibility combined with the flexibility of today and tomorrow’s wireless networks opens up new opportunities, and co-design will play a key role [3]. Re-considering design choices for control applications to accommodate wireless communication is a significant demand on industrial application developers. But re-considering design choices for applications is also a necessary step to accommodate the trend towards cloudification and cloud-native application design for CPSs.

3.1.2. Trend Towards Cloudification and Cloud-Native Application Design for CPSs

The demand for cloud computing has gained significant traction over the last years. Cloud-native software development practices enable businesses to think beyond on-premise boundaries, attain enterprise mobility, increase scalability, etc. [14,15]. Moreover, in order to exploit the potential of artificial intelligence (AI) and machine learning (ML), existing solutions are shown to be limiting. For instance, the computation capacity of today’s customized hardware is usually inadequate for processing large datasets or executing advanced mechanisms and for training and executing the AI models in real-time and at scale. Therefore, there is an ongoing move in industry towards cloudification of applications [16]. With the desire of executing applications from the cloud, consequently, there is a rising focus to offload functionality from physical systems—and transition to cyber–physical systems (and a move from embedded control to networked control)—which is driving industry digitalization and the benefits it can bring [10]. Cloud computing facilitates low-cost, scalable access to vast computing power in the digital domain, enabling optimizations driven by data and machine learning (in control, predictive maintenance, fault root-cause analysis, system planning via digital twins) [17]. Offloading also provides simplification benefits (footprint/size, weight, power consumption, complexity, and maintainability) for the physical systems. This drives the interest in offloaded and networked control, often in combination with wireless connectivity [1,17,18]. Since introducing cloud execution for monolithic applications is considered to be inefficient, instead the move is towards cloud-native applications [19]. For this transition as a first step decomposing the control program into functions that support efficient resource usage is needed, and in a next step developing fully cloud-native control applications [19]. For critical real-time applications, challenges do not only arise towards the communication platform (as described in the previous section) but also towards the computing platform: real-time control applications typically have well-defined timeliness constraints. Therefore, processing must be performed within the defined time constraints, or it is considered a failure [20,21]. Thus, determinism is required for cloud execution and applies to all layers that make up the cloud stack. Such determinism cannot be found in today’s cloud computing environments. In summary, communication as well as computing aspects need to undergo a change in order to exploit technologies such as AI, ML, etc. [22].

3.1.3. Trend Towards Flexible Interaction and Interoperability

The trends towards wireless communication and cloud-computing/cloud-native application design highlight how new players enter the CPSs’ ecosystem. At the same time, vendor dependability and lock-in is not desired by enterprises and, therefore, more and more end-users express a need for more flexibility and vendor-independence, which in turn increases the need for open interfaces and explicit integration of systems and sub-systems (from multiple vendors and suppliers) between all entities. This has given rise to a platform business starting to become established as well as new types of service offerings (e.g., software-as-a-service (SaaS) [23], Communication Platform as a Service (CPaas), Global network API platform [24], and robot-as-a-service (RaaS) [25]). Unified non-vendor specific interfaces are increasingly requested and, in particular, in the smart manufacturing ecosystem, OPC UA [26] is starting to establish itself as a standardized information model and protocol framework that can be used to model physical elements, functions and processes in a standardized and vendor agnostic fashion. Likewise, concepts like the Asset Administration Shell (AAS) [27] aim towards standardizing digital representations and interactions of assets to enable interoperability of Industry 4.0 components in a much wider scope than today’s CPSs achieve. Here, also intent-based automation [28] is starting to obtain traction. The idea of intent-based automation is to enable autonomy in a way that a system can adapt its behavior and generate new solutions instead of following human-defined recipes and policies. Flexibility, interoperability, and automation are an integral part of all of the mentioned approaches. They all contribute to a demand towards application developers to incorporate increased dynamicity and adaptability in their application design. Initiatives like CAMARA [29], the GSMA Open Gateway [30], and the GSMA Operator Platform [31] further support this trend by providing standardized Application Programming Interfaces (APIs) and frameworks that enhance network capability access and flexibility across diverse ecosystems.

3.2. Related and Prior Work

The topic of Communication–Compute–Control co-design has recently gained more interest and importance but has been studied before with different angles and in sub-domains, and substantial prior work exists in these sub-domains. In this section prior work relevant to our contributions is summarized. First, the most relevant domains of prior work from the compute domain and the networked control domain are provided, then, a summary of prior work from practical studies is given, and, finally, first approaches of 3Cs co-design on concept level, similar to this publication, are discussed. For all prior work, the additional contributions are outlined.

3.2.1. Prior Work from the Compute Domain

A disrupting conceptual architecture is introduced in [32], called Cloud Fog Automation (CFA), and it was further promoted in [15]. CFA promotes a transition towards cloud and fog computing, with a unified architecture that can integrate Information Technology (IT) and Operation Technology (OT) domains. The realization of CFA promotes a transition to offload higher layer control functions into the cloud infrastructure, as well as to migrate lower layer processes from purpose-specific hardware to virtualized fog computing infrastructure, where fog computing refers to the deployment of programmable compute capabilities on devices closer to the data source, enabling more efficient data processing and analysis at the edge of the network. Cloudifying the higher layer functions is becoming a common practice in enterprise applications today [15]. In addition, there is active research in the area of cloud robotics, which recently emerged as a collaborative technology between cloud computing and robotics enabled through progress in wireless networking and cloud technologies [33].

The device-edge-cloud continuum paradigm described in [34] aims at making use of a distributed cloud-edge infrastructure to run applications on heterogeneous hardware and different locations wherever they perform best. Cloud-native technologies such as containerization, a lightweight virtualization alternative [35], as well as dynamic orchestration have proven to be advantageous over Virtual Machines (VM) [36]. The vision of CFA inspired the framework of RoboKube to accelerate the CFA practice in the robotics domain to seamlessly deploy, migrate, and scale applications across the device, edge and cloud continuum [37] with wireless connectivity [18].

All of the above-mentioned cloud-related work incorporate the co-design methodology in some way, since they optimize the cloud deployment of the application. However, a high-level, systematic framework is not included in these studies.

3.2.2. Prior Work from Networked Control Systems (NCSs) and Wireless NCSs Domain

The idea of making control applications adapt to the environment for increased robustness or better performance has already been gaining interest in the literature. Several articles center around the area of Networked Control Systems and Wireless NCSs (WNCSs). NCSs concentrate on how controllers, sensors, and actuators are connected over a network and with the consequences thereof, e.g., the effects of network characteristics on the control performance. NCS have been used in several areas such as industrial automation, automotive, and teleoperations as discussed in a survey paper from Zhang et al. [38]. The authors of [39,40] and the references therein investigate how network imperfections affect the control performance of NCS. This effect is even more articulated in the area of Wireless Networked Control Systems (WNCSs), where the control system components communicate through wireless connections and are thereby facing non-zero delay and message error probability in data transmissions [12]. Thus, WNCS introduce some novel control design mechanisms to tolerate delay and message losses [13,41,42]. A comprehensive overview on WNCS is also offered in [43], focusing on the communication perspectives. They highlight the need for a joint design within WNCSs, to build a well-performing WNCS,, including the joint design between communication and control, edge-assisted network design, and goal-oriented communication in WNCSs. The mechanisms proposed for NCSs and WNCSs typically either handle the co-design as a joint optimization problem or operate on low-level, focusing on stochastic fluctuations and relying on control theory-based approaches.

3.2.3. Prior Work from Practical Studies

There are a few practical studies around co-design where real scenarios are also taken into account. For example, a case study is discussed in [44] where a latency-aware wireless control framework is presented and employed in a real ball-and-beam control system. The authors discuss the differences in the co-designed system compared to the independent design approach and show improved robustness of the system. In [45], another case study with cloud controlled Autonomous Guided Vehicles (AGVs) is provided to show how co-design can facilitate the lowering of the consumption of wireless network resources. The proposed solution resulted in lower probability of system instability and higher number of admissible AGVs. Lyu et al. [46] worked on a network hardware-in-the-loop (NHiL) framework to evaluate the impacts of wireless network on robot control and then to improve the design by employing correlation analysis between communication and control performances. The proposed method eliminates the huge efforts and costs of building and testing the entire physical robot system in real life.

While these works are very valuable for taking a realistic approach, they investigate very specific co-design algorithms and do not discuss a generic co-design framework.

3.2.4. Prior Work on Concept Level

A recent concept work on this topic discusses the necessity and the potential of co-designing the communication and control system, highlights the importance of tight interaction between communication and control systems, as well as identifies some opportunities, technical challenges, and open issues [3]. Our contribution compared to this work is that we propose a structured, general framework for co-design and in addition extend the scope with considering the cloud domain as well.

A significant part of the existing literature focuses on formulating a joint optimization problem to solve the co-design of communication and control. The authors of [45] analyzed and summarized the existing co-design methods and identified two kinds of problems: (i) control optimization problem with communication constraints and (ii) communication optimization problem with control constraints. Some parameters influence both the control and communication systems at the same time, which is the key to communication–control co-design. The example of a cloud-controlled AGV is provided, where the control parameters are optimized to achieve a higher coding rate threshold and lower probability of system instability.

The solutions mentioned above formulate the problem analytically and target a typically complex, optimal solution of the problem. However, a key contribution of the work described in this article is the split of the co-design problem into smaller, pragmatic steps to be tractable and be able to adapt to the actual application needs, since not all kinds of applications require the same level of co-design.

The dependability and programmability of communication and compute systems have been identified as a key essence required in infrastructures to support critical real-time applications [47,48]. Dependability is a collective term that comprises characteristics of availability, reliability, and maintainability [49]. The framework described in this article builds on the concept of dependability and applies it to services and application design. A dependable industrial service is designed such that it can be trusted to provide the desired value/outcome with a quantifiable probability. Similarly, a dependable application is designed to bound uncertainties (e.g., communication latency) to deliver a trusted outcome. A tabular summary of the most relevant prior art is added to

Table 1. Tabular summary of related works.

Ref.	Domain	Theoretical/Concept Work	Practical Aspects	Findings
[15,32]	Compute	Cloud-Fog Automation (CFA) architecture	Measurements in real-time control systems	CFA is needed, but major challenges are still open (latency, reliability, time synch., etc.). Possible promising direction is control-communication co-design.
[33]	Compute (survey)	System-level architectures facilitating the collaboration of cloud computing with advanced robotics	Specific robotics applications and the corresponding domain knowledge	Gaps and future research directions are identified for higher utilization and inclusion of cloud-based robotic systems in real-life problems.
[35]	Compute	Performance evaluation methodology of containerized edge-cloud architecture	Edge-cloud connectivity models benchmarked	The performance of current edge-cloud implementations with respect to. concurrency, RTT and message sending interval must be improved.
[36]	Compute	Framework of RoboKube	Robot teleoperation	RoboKube accelerates CFA and facilitates the integration of cloud and ROS ecosystem.
[39,40]	NCS (survey)	Network imperfections impact on control performance	Mobile robots, drones	New communication solutions needed to improve the flexibility and decrease time-dependability.
[13]	NCS (survey)	Protocol design for wireless industrial communications	Ultra-wideband (UWB) and cognitive radios	Wireless sensor networks and UWB technologies are promising approaches.
[42]	WNCS, control theory	Robost MPC-based solution against packet loss	Evaluation against normal MPC	Solution incorporates explicit bandwidth constraints and is robust to bounded packet loss.
[44]	Co-design of communication and control	Internal model control-inspired latency-aware wireless control framework	Realistic evaluation using Ball-and-Beam case study	Proposed framework eliminates the efforts of building and tuning entire controller in real control system.
[45]	Co-design of communication and control	Existing co-design methods summarized	Cloud controlled AGV	Optimized AGV controller lowers resource consumption.
[46]	Co-design of communication and control	Network hardware-in-the-loop framework	Several realistic robot control use cases	Framework provides more trustworthy results than statistical modeling.
[3]	Co-design of communication and control	Co-design opportunities, challenges, and open issues	Packetized predictive control case study	Co-design can reduce the gap between the requirements of real-time control systems and the performance of today’s wireless systems.
[47,48,49]	Dependability of communication and compute	Dependability concept for critical real-time applications	Smart farming, adaptive manufacturing, XR	Dependability of communication and compute are required in infrastructures to support critical real-time applications.

.

4. The Framework of Communication–Compute–Control-Optimized Application Design

4.1. Co-Design Framework

In this section, the framework of Communication–Compute–Control design is explained. It provides a structured way of grouping application design approaches according to their needs on dependability and relate these to the knowledge, insights and interactions with the communication and computation infrastructure that could support enhanced application design. The underlying principle is that the more intelligent an application becomes, the higher levels of criticality/dependability it can accomplish when executing its tasks. There are two main ways of achieving a higher application intelligence: (1) via smarter algorithm design, e.g., innovative new approaches from the control domain; (2) by obtaining relevant information and exploiting additional knowledge from other sources. This work has a strong focus on exploring the latter approach, which aims for improved application scalability and robustness. The application intelligence is enhanced by exploiting additional knowledge from the network/compute infrastructure. A framework can then be developed by grouping this additional knowledge obtained from the network and compute domains into different degrees ranging from simple to advanced insights together with the different mechanisms to obtain this knowledge. This conceptual structure can then serve application developers to support or guide in choosing the right type of insight and interaction with the network/compute infrastructure depending on the requirements and technical needs of the application. Moreover, the framework allows for a structured identification of challenges, research questions, and required improvements related to the different building blocks involved. The framework is illustrated in

Table 2. Different degrees of 3Cs application design.

Degree	Description of Application Design Approach	Type of Application
0	Unawareness Control applications with no awareness of network and computing resources.	Non-critical applications with no requirements towards dependability.
1	Co-design with awareness Control applications with awareness on general characteristics of network and compute.	Non-critical applications with limited requirements towards dependability.
2	Co-design with interfacing for information sharing Control applications designed using exposure interfaces towards network and/or compute.	Non-critical/critical applications with moderate requirements towards dependability.
3	Co-design with interaction for configuration Control applications designed using exposure interfaces as well as making service requests towards network and/or compute.	Critical applications with stringent requirements towards dependability.
4	Co-design with negotiation Control applications designed to negotiate with network and compute infrastructure to achieve a common overarching goal.	Critical applications with stringent requirements towards dependability optimized in a larger context.

. For different degrees the different design approaches of the application are detailed together with the required interaction/interfacing towards network/compute infrastructure. Each degree is mapped to an application approach according to the criticality/dependability of the application. The knowledge insights and interactions that the application exploits start from the lowest degree (with no insights and no interaction). With every degree the detail of knowledge/insights available to the application about network/compute infrastructure increases (general awareness, specific knowledge, etc.) by using increasingly sophisticated interaction mechanisms. At the same time, with every degree, when exploiting the additional knowledge, the application cannot only guarantee increasing levels of dependability but also ensure increasing levels of resource efficiency.

The reason for taking this approach is that the decision on what type of 3Cs design is needed should continue to primarily lie in the hands of the application developer. The application developer knows, understands, and controls the application needs. At the same time, in order for the application developers to make the best use of communication and compute infrastructure, easy-to-use interfaces providing insightful information about these infrastructures are important. The means of interaction to support the application developer should be simple and suit the envisioned purpose.

The framework as it is depicted in Table 2 has its focus on the application and information/insights/interaction exposed by network and computing domains towards the application. However, with increasing degrees of co-design, the network and compute domains can also directly or indirectly gain more insights about the application. This additional knowledge allows those domains to adjust, re-configure, or optimize in order to support the application. Note that conventional non-co-design methods correspond to degree 0.

4.1.1. Degree 0: Unawareness

In this degree, the application is designed with no awareness of the characteristics of neither the network nor the computing infrastructure it makes use of.

• Additional knowledge utilized by the application: None.
• Type of application: This type of application design has its justification for, e.g., applications with unlimited access to computing resources, as well as for wireless non-critical applications when, e.g., usage of computing and communication resources is so limited that access to these can almost always be assumed feasible under perfect conditions.

While this approach benefits from simplicity, it suffers from the fact that no notion of dependability can be achieved. Any type of resource constraint may lead to an unsuccessful operation of the application.

4.1.2. Degree 1: Awareness

In this degree, the application is designed with awareness about the general characteristics of the networking and the computing infrastructure. By exploiting this knowledge, the application can be designed more intelligently in comparison to degree-0 applications. As an example, the application may be aware that delay, jitter, or loss of application data may occur in wireless networks and when using external computing infrastructure. While basic applications may simply only accept that there is an imperfect link, more advanced applications could adapt to certain changes such as latency.

This leads to the following characteristics for the degree-1 design:

• Additional knowledge utilized by the application: Understanding of general characteristics of network/compute, e.g., awareness that resource constraints may occur;
• Type of application: Typical applications for which degree-1 design is suitable are non-critical applications that are using only very limited compute or network resources or that can be run with resource allocations following the default best-effort paradigm.

This degree benefits from its simplicity, but still the application is designed to deal with some performance uncertainties in the communication and compute and adapts its operation accordingly. This is a basic step towards increased application flexibility and adaptability.

4.1.3. Degree 2: Interface Exposure

In this degree, the application is designed to actively make use of interfaces, e.g., Application Programming Interfaces (APIs) to obtain more specific information and insights about the network and computing infrastructure. This information brings additional knowledge to the application than the general awareness about communication and computing infrastructure as in degree 1. By exploiting this additional more specific knowledge, the application can now be designed to also perform critical tasks with higher levels of required dependability. This leads to the following characteristics for the degree-2 design:

• Additional knowledge utilized by the application: information on the current or predicted operational status of the network/compute domains, including, e.g., upcoming resource constraints or resulting performance variations;
• Typical application: This type of application design is most suitable for applications solving moderate/critical tasks with a moderate degree of guaranteed accomplishment.

This application design approach benefits from more detailed insights about network/compute for more advanced handling of varying conditions without having to request more advanced services from network/compute, which may come with additional costs. Applications can benefit from some resilience or fallback behavior, which can be activated in, e.g., resource constrained situations.

4.1.4. Degree 3: (Mutual) Interaction

In this degree, the application is designed not only using exposure interfaces to obtain information from the network and cloud domains (as in degree 2), but also for triggering specific service requests towards the network and/or the compute entity. These requests typically demand changes in the services provided by the network/compute infrastructure, potentially related to network/compute configuration aspects. A typical request could involve demanding communication (e.g., Quality-of-Service (QoS) requests) and computing resources with strict communication demands on timeliness and reliability unlike best effort performance. A further enhancement of this type of service request would involve the expression of service needs via intents. This leads to the following characteristics for the degree-3 design:

• Additional knowledge utilized by the application: More detailed performance insights on specific network/compute infrastructure that can be provided. Moreover, the application can now rely on service assurance of communication/compute infrastructure and can work with a quantifiable assessment of their dependability;
• Typical application: This type of application design is most suitable for accomplishing tasks with high levels of required guaranteed accomplishment and/or applications that require significant amounts of resources and/or applications that need to operate with high levels of resource efficiency. By ensuring access to communication and/or compute resources via service requests, the highest degree of guaranteed task accomplishment can be achieved.

This application design approach comes with the advantage that the application developer can rely on dependable communication and compute services via explicit requests. With adaptability implemented in the application, resources are only requested when needed. Moreover, if the network and the compute infrastructure implement dynamic and flexible resource allocation this would allow for a more optimized utilization of the resources as well as a higher number of applications potentially being supported.

4.1.5. Degree 4: Negotiation

In this most advanced degree of co-design approach, it is envisioned that an application is designed using knowledge about its context and intents towards an overarching common goal it contributes to. Communication and compute resource allocation could then carry out negotiation principles to determine an optimal distribution and timing of resources to achieve the overarching goal. This degree can very well benefit from the concept of intents. This leads to the following characteristics for the degree-4 design:

• Additional knowledge utilized by the application: Increased understanding of relations and resource dependencies towards other applications in a wider context.
• Typical applications in this degree could be part of a larger context, for which a higher-level task/application coordination exists. This could for instance be in the form of digital twins. The negotiation process would then take place or relate to a higher level, e.g., between some notion of network, compute, and system digital twin.

This is the most advanced application design and requires complex knowledge and interactions.

4.1.6. Summary

Figure 4 depicts a flow-chart summarizing the basic steps for understanding a suitable degree of co-design depending on the application’s needs and the environment/context it operates in. Note that this is a very simplified view and only depicts the most important steps.

Table 3. Advantages and challenges of co-design degrees from an application perspective.

Degree	Key Advantages of the Approach	Challenges of the Approach
0	Simplicity in application design.	Fails to support the application if resource constraints or variation in network/compute conditions may occur.
1	Simplicity in application design. Allows for handling of a very limited variation in resource conditions.	Requires a general high-level awareness of the application on the network/compute resources it needs. The application needs to implement simple handling of varying resource conditions.
2	Allows for more advanced handling of variations in resource conditions. No need to implement other than best-effort service requests.	Requires self-awareness of the application to understand own needs to respond to changing conditions in network/compute resources. The application needs to implement more advanced handling.
3	The application can rely on dependable communication and compute services via explicit requests. Dependability builds on “contractual” (explicit) interactions. Resilient application design for highest levels of dependability. Efficient use of compute and network resources.	Requires detailed self-awareness of application/network/compute on own needs and requirements to support and request future services. Additional implementation complexity to handle and switch between different operation modes and request other than best-effort services.
4	The application contributes in the most constructive way towards a larger context.	Automated negotiation principles with potentially conflicting interests.

summarizes advantages and challenges for the application for the different degrees.

If an application has changing needs with respect to dependability, the same flowchart can also be applied for understanding the degrees suitable for different operation modes of an application depending on current needs. By keeping application implementations for operations that do not require advanced levels of dependability to the lower co-design degrees, the overall complexity of an application can be kept low.

4.2. Examples of Use Case Realizations Using Co-Design with Different Degrees

To illustrate the applicability of the framework, we explore in the coming subsections for the example of Autonomous Mobile Robots (AMRs), how a 3Cs co-design approach for AMRs can benefit from the different degrees of co-design. Each degree represents a different level of complexity, integration, and responsiveness between the AMR, the compute platform, and the network.

4.2.1. AMR Use Case Scenario and Assumptions

For this use case, we consider deploying an AMR following the principles of cloud-fog-automation within the device-cloud continuum. The software stack is composed mainly by three blocks, each cloudified to enable seamless deployment and integration across devices, edge, or cloud environments, depending on the prevailing conditions. Additional tasks are usually added, e.g., object detection, object tracking, or other heavy AI processing. The three blocks are:

• Localization: This component consists of a set of entities designed to provide an accurate localization system. It enables the robot to determine its position within the environment and detect obstacles. For example, Simultaneous Localization and Mapping (SLAM);
• Navigation: Building on the localization system, the navigation component comprises entities responsible for moving the robot within the environment. This includes trajectory and motion planning, allowing the robot to travel between points A and B;
• Hardware-dependent functions: This component contains entities that are specific to the hardware running on the robot and cannot be offloaded to the edge or cloud, such as servo control, sensors, and safety and emergency mechanisms.

Each of these components are tightly interconnected, with varying communication and computation requirements.

Figure 5 illustrates the architecture of the AMR. In the example, the computationally heavy parts of the application, here navigation and localization, are offloaded to the edge or cloud. The hardware-dependent functions, e.g., for controlling the drives, are embedded into the AMR platform. A safe fallback solution not requiring any network or compute resources allows the robot to stop safely if resources are not available.

The scenario is as follows: An AMR operated in an outdoor public area is tasked to move from point A to point B. Its performance, measured by the time the AMR takes to complete the task, is a critical factor in determining the Quality of Experience (QoE), as it directly impacts user satisfaction and the perceived efficiency of the system. Since the AMR is placed in a public area, it is operating in an unstructured environment, where humans, cars, etc. are moving around creating changes/obstacles in the environment and impacting network conditions. The AMR is required to navigate in this environment, finding the fastest path from A to B despite the dynamic changes.

The following assumptions are made:

• The AMR is navigating in an environment where there is a high density of connected cars, sensors, devices, humans, etc., competing for both communication and computing resources. (see Section 2 on trends towards wireless communication).
• The AMR is implemented in a cloud-native way, using container orchestration platforms to simplify the deployment and management of the application in the device-cloud continuum. (see Section 2 on trends towards cloudification).

In the following, the same scenario is played out for the different co-design degrees, showing how the increases in insights and the more and more advanced interactions benefit the use case.

Co-design with unawareness, degree 0, corresponds to a reference case, where the localization and navigation in their default functionality are simply offloaded to the edge cloud, relying on the network capability as it is.

4.2.2. AMR Co-Design with Awareness, Degree 1

The AMR is designed with an understanding that its operation requires network and computing resources and is aware that there may be resource constraints. Since in this degree it is assumed that the AMR is not designed with the capability to make specific performance requests towards network and compute, the AMR can only operate in best-effort mode. In case resources become constrained, the AMR halts its mission, standing still, waiting until resources becomes freed up again. This may happen several times on its trajectory from A to B and, therefore, this potentially leads to unpredictable completion times of the task of the AMR. The awareness, however, can be exploited to make the robot control algorithms more resilient against shorter glitches due to temporal network or cloud issues, e.g., continuation of trajectory during a short period of time even during lost connections.

4.2.3. AMR Co-Design with Interface Exposure, Degree 2

Similarly to co-design degree 1, the AMR knows its requirements and technical needs towards the network and compute infrastructure and operates in best-effort mode. However, with a degree-2 design the AMR is enabled to request information about network and compute, and, thus, obtain additional insights, e.g., the robot control application can obtain in advance information from the network/compute infrastructure about predicted resource constraints over time/in certain areas, or receive insights into the expected range of computing times or communication latencies [50,51]. With this information the AMR can pro-actively adjust its trajectory and plan ahead. This will allow the AMR to operate more robust and smoothly (less frequent stops) from A to B. Furthermore, the task completion time becomes more predictable. Since operation is, however, still on best-effort support from network/compute infrastructure, critical applications cannot be guaranteed to be supported in an optimal way since the AMR has to adapt to the availability of compute and communication resources.

4.2.4. AMR Co-Design with Mutual Interaction, Degree 3

Similarly to co-design degree 2, the AMR knows its requirements and technical needs towards network and compute and is designed to use information exposed by network and computing infrastructure. On top of that, with degree-3 design it is enabled to make specific requests towards the network and the compute infrastructure detailing its needs for dependable services. If these dependable services become granted, the network and compute infrastructure manage their resources such that the requested resource usage of the AMR can be fulfilled—at least with high likelihood—even during resource fluctuations. As a result, the AMR can move from best-effort operation to dependable operation. The task completion time becomes predictable. The AMR can be implemented such that there exist different operation modes with different needs and requirements towards dependable services from the network/compute infrastructure. The AMR can then choose a suitable operation mode in a resource constrained scenario and adapt its operation pro-actively by switching to different operation modes.

4.2.5. AMR Co-Design with Negotiations, Degree 4

The AMR is designed with the same level of awareness and capabilities as in degree 3 but on top of this, in degree 4-design, the AMR is aware of its context. In the case of resource constraints, the AMR actively participates in a negotiation process with other involved actors in the system, e.g., by suggesting alternative operation modes that it could switch to, in order to free-up resources. Towards this purpose, the AMR can express its intents in an abstract format and can flexibly adjust its behavior, e.g., changing priorities, traffic profile, etc. Thereby, the AMR contributes to finding solutions for problems that are larger than its own scope.

4.2.6. AMR Co-Design with Different Degrees for Different Segments

As already indicated in the degree-3 design, AMRs may also be designed to implement more than one degree of co-design. This is for instance suitable when the operations of the AMR have different levels of criticality at different times; an AMR executing low-priority missions may at times receive high-priority missions. When executing the high-priority missions, the AMR switches to co-design degree 3 routines, while during low-priority missions, an operation at degree 2 is good enough, thereby freeing up resources for other users in the system.

4.2.7. Discussion

The example of different co-design degrees implementations for AMRs have highlighted the required interactions of the AMR for the different degrees, as well as the outcome that can be expected regarding the execution of the AMRs operation. The example furthermore demonstrates how increased flexibility and adaptability in application design together with co-design degrees 3 (or 4) ensures a more resilient execution of the application. At the same time, resources are used in a more efficient way.

AMRs are only one example where co-design is foreseen to provide major benefits. But the framework is applicable to any dependable application requiring both communication and compute resources for its execution. For instance, in [49], dependable and adaptive service design for 6G networks is explored for the examples of exoskeletons, XR for industrial workers, adaptive manufacturing systems, and smart farming use cases.

Practical evaluations and case studies are ongoing or the subject of future work. A first evaluation that classifies as co-design degree 3 is provided in [52], where the operation of time-critical applications for 5G-enabled unmanned aerial vehicles (UAVs) is studied to determine how their operation can be improved by the possibility to dynamically switch between QoS data flows with different priorities.

5. Building Blocks of 3Cs Co-Design

The framework described in this article has identified flexibility, adaptability, and interaction as key ingredients to enable co-design. In this section the building blocks for achieving a next level of flexibility, adaptability and interaction are outlined together with pointers towards first solutions, contributing technologies, etc. Moreover, research gaps are identified.

Figure 6 illustrates the building blocks of co-design across the 3 different domains and their relationship on a conceptual level. For each of the domains, the same blocks have been identified to be highly relevant. These are (1) self-awareness, (2) evolved exposure mechanisms and interfaces, and (3) planning, decisions, and actions. Each domain (i.e., network, compute, and application) in the co-design approach can enhance its own capabilities by developing and improving its own building blocks independently from the other domains. However, for applications with mission critical requirements, the benefits of co-design are more pronounced when all the three domains evolve jointly. By using exposure mechanisms and interfaces, interactions between the domains become possible. Finally, decisions and actions are determined in each domain and across domains aiming for an overarching 3Cs co-design.

5.1. Self-Awareness, Decisions, and Actions

One building block towards improved understanding of capabilities and towards co-design is self-awareness. Self-awareness in this context refers to the understanding of a domain about its own capabilities as well as its needs and requirements. Today’s applications, compute and network infrastructure have already a certain level of self-awareness. Co-design benefits are foreseen by further increasing this self-awareness, e.g., in its granularity over time, space, etc. In general, for increased self-awareness and control of all three domains, internal observability is a key capability to develop advanced insights. Self-awareness is moreover a key pre-requisite for developing advanced decision-making algorithms within a specific domain. To this end, various approaches can be applied, e.g., model-based approaches or data-driven approaches (leveraging machine learning), or a combination thereof. Increased self-awareness together with external insights obtained via exposure interfaces will allow for more advanced decision taking, both within and across the domains. The building block self-awareness, as needed for co-design, is explained together with the possible impact on the decision, actions, and algorithms building block in more detail per domain in the following.

5.1.1. Application Self-Awareness, Decisions, and Actions

Self-awareness of an application entails that the application can clearly define in a service specification the performance requirements towards the network and compute platforms and the level of guarantee/dependability that needs to be provided to achieve its own desired quality of experience. The service specification(s) need to be sufficiently granular in characteristics of the application’s communication traffic and compute demand, as well as in performance requirements and their criticality over time. The service specification should enable the communication and compute domains, to assess if and how such a service request can be supported at the required performance level and with an availability level that matches the criticality of the performance need.

Advanced self-awareness would then allow for a more dynamic application design in terms of decisions, actions, and algorithms. Increasing the flexibility and responsiveness of an application towards changing network/compute conditions can provide application resilience and is seen to become of increasing importance in this context. As an example, advanced self-awareness could entail that an application is designed to make service requests towards the network and compute platforms not only for the worst-case scenario with respect to network and compute performance (i.e., targeting the minimum performance requirements) but also for a “normal” or “preferred” operation mode. That is, the application is aware of its changing needs towards network and compute performance based on its own operational state, which may change over time. The application may support from one to several specific operation modes, which all should be well-understood by the application, e.g., in terms of performance requirements and expected execution guarantees as well as the characteristics of the traffic for a given operation mode and the need on compute capabilities.

Awareness, planning, and prediction of an application’s service specifications into the future are seen to become increasingly important in this context. In particular, when facing resource constraints from network and/or compute, re-planning, and re-assessment may potentially be required on a more frequent basis.

5.1.2. Network Self-Awareness, Decisions, and Actions

For network services providing more than best-effort guarantees, the network needs to be able to specify what services can be offered (in terms of supported performance levels) together with an assessment of the dependability (availability, reliability, maintainability) for such services. This means it should understand which performance levels (e.g., related to latency, jitter, data rate, etc.) it can guarantee at which availability level. Application developers should cater for an application design that can benefit from such insights and provide not only high performance to the application but also the resilience that allows adapting to changing network characteristics. The network needs to continuously monitor and assess its own capabilities to obtain its own awareness about when, where, and under which conditions (e.g., traffic load) the specified connectivity services can be guaranteed. The network should not only be aware of its capabilities at any specific moment in time during its operation, but it should also be able to plan and predict its capabilities into the future. To be able to provide a dependable network connectivity, in addition to an anticipated (e.g., average) performance level, there needs to be an assessment of the order of magnitude for a guarantee that can be associated with the performance level (i.e., quantile-prediction). If the bottleneck is identified, the network should be able to assess what potential actions should be taken to mitigate that bottleneck.

5.1.3. Compute Self-Awareness, Decisions, and Actions

For compute services providing guarantees, the compute infrastructure needs to be able to specify what services can be offered together with an assessment of the dependability (availability, reliability, maintainability) of these services. If further, more detailed capabilities can be guaranteed (e.g., related to fault-tolerance and bounded compute execution times) this should be visible to application developers. The compute infrastructure needs to continuously monitor and assess its own capabilities to obtain an own awareness about when, where, and under which conditions the specified compute services can be guaranteed. Also, the compute infrastructure should extend its self-awareness and allow it to plan and predict its capabilities into the future. If the bottleneck or root-cause for a limitation is identified, the compute infrastructure should be able to assess what potential actions could be taken to improve the compute infrastructure.

5.2. Exposure Mechanisms and Interfaces

Exposure mechanisms and interfaces play a crucial role in the information exchange between the 3Cs domains, and it is one of the identified building blocks towards co-design. Exposure refers to the capability of one domain to provide information about its capabilities and characteristics to external consumers via some API. It also allows for service requests or configuration requests to be received. The need for standardized interfaces and mechanisms has been identified and is ongoing work. For example, when it comes to interfaces towards the network infrastructure, in [53], the need of industrial automation systems has been described to be able to obtain information about network capabilities and request connectivity services. In [54,55] it has been demonstrated how an industrial automation system can obtain characteristics from a 5G network, configure connectivity relations between industrial automation assets via 5G, and request connectivity services with appropriate QoS according to the needs of the applications running between the industrial automation assets.

While there are many parameters and characteristics that could potentially be exchanged between application, compute, and network to increase knowledge and insights among the 3Cs domains, the content of the information exchanged should be limited to what is actually used and provides a value, that is, purpose-driven information exchange is desirable. A typical purpose-driven information element from application to network and compute infrastructure are requests for services, e.g.,:

• Requests for specific connectivity and compute services or a change in these;
• Requests for network and compute information and requests for subscribing to a specific information channel from network and compute elements, e.g., notifications about changes in network and compute conditions.

With increased self-awareness, every domain can choose to expose more information, as well as more advanced and potentially more insightful information to other domains. But not every insight obtained in a domain is relevant for the other domains at all times. Therefore, also the way information and insights are shared should be conducted in a purpose-driven format. Suitable data exchange patterns may involve, e.g., publish–subscribe data exchange patterns, request–reply data exchange patterns, etc.

5.3. Example Flow of Interactions

Given the building blocks of co-design illustrated in Figure 6 and described in the previous sections, below an example flow of interactions is outlined for degree-3 co-design.

• Self-awareness: All entities (network, application, compute) evaluate their own needs and requirements with suitable time intervals, keeping an updated view. This is performed by each entity independently.
• Exposure of self-awareness information via a suitable method, thereby giving the other entities the possibility to consume this knowledge.
• Planning and decision making: Each entity acts based on self-awareness and by consuming exposed information and potential requests from the other entities. If there are different alternatives of actions, conflicts, or a decision on an action is made an iterative process is foreseen, e.g., starting with updating self-awareness.

6. Navigating Co-Design, Tradeoffs, Considerations, and Next Steps

The framework introduced in this article makes an attempt to structure the challenge of co-designing applications across the 3Cs domains to allow for breaking down the problem into smaller sub-problems. While this approach contributes to a simplification, there is still a high degree of complexity that remains to be solved. In this section, some important tradeoffs and considerations are discussed. Furthermore, directions are given regarding important research and development that emerge from these discussions.

6.1. Complexity vs. Simplicity

Throughout this article the value of increased adaptivity and flexibility in the 3Cs domain have been highlighted. However, improvements in adaptivity and flexibility typically come with a cost of increased complexity, both during the implementation phase as well as during the operation phase, e.g., for the application design, higher complexity may result in more costly updates, maintenance, etc. The same holds for communication and compute infrastructure. Obtaining insights to improve self-awareness and share these externally comes with additional costs towards observability and developing interfaces. However, with the ongoing move towards cloud-native application design, the cost in complexity may be outweighed by the increased efficiency and flexibility, also when it comes to updates. Still, obtaining a better understanding of value vs. costs for the different co-design degrees to guide application developers could be a valuable next step to explore.

The tradeoff of complexity vs. simplicity is also a key consideration when moving towards degree 4 of co-design, where advanced negotiations are foreseen to be the main differentiator. This area is just in its infancy, and so far, only high-level concepts exist.

6.2. Technology Specific Insights vs. Technology Agnosticism

Self-awareness, sharing specific insights and at the same time exploiting insights outside the own domain have been highlighted throughout the article being of key importance for 3Cs design. There is, however, a tradeoff between the level of detail with respect to very specific insights that could be provided, bringing potentially higher gains to the specific scenario and on the other hand aiming for a technology-agnostic application design. Therefore, with an increased exchange of insights and knowledge between the 3Cs domain a framework has to be determined that should be agnostic to the technologies that are used and that does not depend on the underlying hardware and programming platforms. Instead of sharing specific information about these, an abstraction should be made towards capabilities. This would furthermore enable interoperability. Towards the challenge of ensuring technology agnosticism a number of efforts are ongoing: One example is the connectivity framework layer brought forward by IIC [56] that aims at ensuring interoperability by exchanging data that is structured in a common, unambiguous data format, independent of endpoint implementation, and decoupled from the hardware and programming platform. Continued research and development have to go into technologies that enable integration of diverse systems and sub-systems, with the ambition of reducing vendor lock-in and fostering innovation.

6.3. Domain Interaction and Modeling of 3Cs Interaction

A main conclusion from the 3Cs framework is that 3Cs co-design requires interaction between different domains and potentially very different types of components. At the same time this information exchange needs to be based on meaningful insights. The interaction needs to be addressed in a way that ensures that the modeling of these interactions is performed in a standardized and vendor agnostic fashion since co-design can be applied to diverse systems and sub-systems. This is in particular of importance in scenarios with multiple suppliers and heterogeneous technologies. Key frameworks and standards like OPC UA [26], or the Asset Administration Shell (AAS) are taking an important step towards promoting interoperability, flexibility, and automation between different ecosystems. A promising approach is to use the standardized information model and protocol framework OPC UA to model physical elements, functions, and processes. The OPC UA Information Model framework could be used to model the different 3C components, and to expose events and methods to support the different features (exposure, interactions, intents, etc.) of a 3C system. OPC UA supports mechanisms for monitoring events, attributes and states associated with the 3C components. Applications, and 3C components themselves, can subscribe to these events, and trigger different actions, e.g., when an event occurs. The next step could be to further explore how OPC UA References could be used to model the relationships (both physical and functional) between the different 3C components to enable co-design.

6.4. Open Interfaces vs. Proprietary Solutions

The ongoing evolution of wireless communication, cloud computing, and cloud-native application design is reshaping the cyber–physical systems (CPSs) landscape. The adoption of open and standardized interfaces, driven by initiatives such as CAMARA, the GSMA Open Gateway, is driving the next wave of digital innovation by enabling a more interconnected and efficient technological landscape. These interfaces empower developers to focus on creating innovative applications without being constrained by compatibility issues or vendor dependencies. In contrast, proprietary solutions may offer optimized performance for specific use cases, e.g., by enabling tighter integration with certain vendor technologies. However, this often comes with the cost of limited interoperability and vendor lock-in that eventually stifles innovation and restricts the potential for cross-platform collaboration.

With 3Cs co-design envisioned to go across domains and across ecosystems, there is a stronger need for open interfaces than proprietary solutions for this area to grow. Therefore, continued research and development towards open and standardized interfaces is needed. As these efforts continue to mature, they promise to unlock new opportunities for collaboration and growth across the ecosystem, ultimately benefiting end-users with more robust and versatile solutions.

6.5. Scalibility Aspects of Co-Design

One key motivation for 3C’s co-design is to improve overall system resource efficiency. By obtaining a more detailed level of self-awareness, and by consuming information exposed, each entity can optimize its operations in relation to the other entities. With this approach over-provisioning of resources is envisioned to be avoided to a larger extent. The benefit of improved resource efficiency related to co-design is expected to be visible in particular in large-scale systems, where many applications are competing for the same resources.

At the same time, the scalability of co-design comes with its own challenges. The potential overhead created by exchanging insights in addition to information has to be kept to a minimum. Here, in particular, the mechanisms for information exchange have to be chosen carefully, in order to avoid a system overload when many applications want to access common resources. Furthermore, in order to enable scalability, applications that do not benefit from higher-degree co-design approaches should stay on lower degrees. A careful evaluation of the added value provided by utilizing a co-design approach should, therefore, always be made during application design.

6.6. Conceptual vs. Practical Work

While there is starting to emerge more and more conceptual work related to co-design, the realization and validation of work in the co-design of compute, communication, and control for CPSs are crucial for advancing these technologies. Realizing end-to-end testbeds and proofs of concept (PoCs) plays an instrumental role in this process, serving as practical environments where theoretical designs can be tested and refined. These testbeds and PoCs enable a deeper understanding of the evolving interaction needs between compute, network, and application layers. For the co-design area to grow both conceptual and practical work is needed.

While this article does not present any practical results, it sets a foundation for a meaningful comparison between co-design approaches in the research field. As an example, with the co-design framework at hand, different practical co-design algorithms within the same degree-level are meaningful to be compared. Co-design approaches that are not in the same degree are instead more meaningful to compare in order to understand the tradeoff between the complexity added by moving to a higher co-design degree in relation to the additional value created.

7. Summary and Conclusions

This article has introduced a framework that provides a structured approach for analyzing and developing applications in the cyber–physical continuum. The analysis of state of the art and observed trends in industry and academia (Section 3) has shown the need but also several ongoing trends and developments that are moving towards a highly integrated design of CPSs. Ongoing development towards increasing the adoption of wireless communication for CPSs as well as trends for cloudification and cloud-native implementations are paving the way to create the right pre-requisites for enabling a more integrated application design for CPSs. Combined with the general vision of Industry 4.0 for flexible interaction and improved interoperability these trends call for a tighter interaction between different domains and ecosystems. Therefore, the term Communication–Compute–Control co-design has emerged as a collective term for CPS’s design approaches that consider and exploit insights from all three domains.

The prior work analysis (Section 3) showed how contributions to the area of 3Cs co-design come from the different domains, that the need for an overarching concept has been identified, and first steps have been taken in this direction, both with conceptual work as well as practical studies. However, an overarching framework is missing, which this article tries to address. The proposed 3Cs co-design framework is described in detail (Section 4), explaining the different degrees of co-design that an application can be categorized into depending on its needs and requirement. The co-design approach is exemplified for a co-designed autonomous mobile robot with different degrees, showing how the different degrees affect the application design but also the outcome of the use case in the example. The main building blocks of co-design have been outlined in Section 5. A discussion on tradeoffs and important parameters that affect choices when co-designing applications has been outlined in Section 6. Here is also where key research and development questions for future work are described.

To conclude, 3Cs co-design is a promising research and development field aiming for better application performance, improved resource efficiency, and more resilient design of CPSs, which requires interdisciplinary efforts. Its impact stretches all the way from concrete near-term application implementation design to futuristic concept development. There are varying degrees of complexity in co-design due to the different domain interactions, and the many tradeoffs that need to be handled. However, with a structured approach, it is possible to break down complexity and move one step closer to the vision of co-designed applications for CPSs.