Time in computing

Time is a fascinating concept. Much has been thought and written about the physics of time (e.g., Muller, Reference Muller2016), the philosophy of time (e.g., Power, Reference Power2021), the measurement of time (e.g., Struthers, Reference Struthers2024) and the history of time (e.g., Hawking, Reference Hawking2015). In computing, time has precise meanings (Furia et al., Reference Furia, Mandrioli, Morzenti and Ross2012; Buttazzo, Reference Buttazzo2023), such as:

1. (1) The time elapsed between an event and the completion of the correct response (Latency);

2. (2) The maximum time guaranteed for a program to execute (Worst-case execution time, WCET);

3. (3) The maximum time allowed for the execution of a process or a function (Before a time-out);

4. (4) The maximum time for a process to wait for an event, a response or a message (Synchronization);

5. (5) The time interval between measurement values received from a sensor (Input sampling rate);

6. (6) The time interval between outputs to an actuator (Output sampling rate);

7. (7) The trigger times to start a process (Either absolute from Coordinated Universal Time (UCT) or relative to another event or process);

8. (8) Relative timing: Before, not before, after (For events, messages, actions, process start and so on);

9. (9) … and other timing requirements or timing relationships.

Timing is a serious specification responsibility. In cyber-physical systems (CPSs), strict adherence to correct timing requirements is a decisive safety property. Therefore, time-sensitive software is crucial for safety-critical CPSs!

State of the art

The work on reference architectures for CPSs (e.g., Nakagawa and Antonino, Reference Nakagawa and Antonino2024) is not new. Several such architectures have been proposed and are well documented, for example, generic architectures, such as: CPS 5 Components Architecture (Ahmadi et al., Reference Ahmadi, Cherifi, Cheutet and Ouzrot2021), 8C architecture (Sony, Reference Sony2020), NIST Framework for CPSs (Griffor et al., Reference Griffor, Greer, Wollman and Burns2017; NIST, 2017). Or domain-specific architectures, such as: AUTOSAR (https://www.autosar.org/; Rajeev et al., Reference Rajeev, Mohalik and Ramesh2012), Integrated Modular Avionics (IMA Architecture, Gaska et al., Reference Gaska, Watkins and Chen2015). Some architecture-centric standards, such as ISO 26262 (see, e.g., Debouk, Reference Debouk2019) and IEC 61499 (see, e.g., Thramboulidis, Reference Thramboulidis2010; Yoong et al., Reference Yoong, Roop and Salcic2013, Reference Yoong, Roop, Bhatti and Kuo2016), are highly useful. However, these works treat timing as a quality attribute (= measurable or testable characteristics of a system, such as availability, reliability, usability or scalability) and not as a correctness property of the system (= formal requirement that defines and assures the system’s expected behavior), (Lee and Woodcock, Reference Lee and Woodcock2023).

A different approach to handling time is the use of temporal logic. Many types of temporal logic systems exist (e.g., 16 of them are explained in Bellini et al., Reference Bellini, Mattolini and Nesi2000). Temporal logic extends classical logic by defining temporal operators, allowing engineers to model and reason about the behavior of systems over time. Using temporal logic is a powerful methodology in software engineering, applicable to the specification, verification and design of programs, algorithms and databases (e.g., Bolc and Szalas, Reference Bolc and Szalas1995; Furia et al., Reference Furia, Mandrioli, Morzenti and Ross2012; Kröger and Merz, Reference Kröger and Merz2008). Temporal logic expresses timing well, but cannot define and express the system architecture (Structure, relationships, attributes).

A different, generic, layered architecture has been proposed by Ungureanu and Sander (Reference Ungureanu and Sander2017). Their proposal utilizes different constructs, including the tagged signal model, the functional programming paradigm and algorithmic skeletons. An additional framework is developed by Abdellatif et al. (Reference Abdellatif, Combaz and Sifakis2010) and Buckl et al. (Reference Buckl, Gaponova, Geisinger, Knoll and Lee2010), focusing on timing and safety.

The progress of this paper is a conceptual architecture with explicit, formalized, verifiable timing at all levels of the architecture and all steps of the lifecycle of the CPS:

Elevating timing from a quality attribute (= measurable or testable characteristics of a system, such as availability, reliability, usability or scalability) to a correctness property of the system (= formal requirement that defines and assures the system’s expected behavior);

Proposing a layered architecture that respects the proven, well-documented architecture principles, such as layering, partitioning, modularization, loose coupling, separation of concerns and so on. (Furrer, Reference Furrer2019, Reference Furrer2022);

Combines accepted constructs for timing definition, verification and implementation (Process algebra, transition systems, Petri Nets, TTCs.

Layered architecture proposal

Context: All development and evolution mechanisms for time-sensitive software – from specification to operation – must have the proper constructs for correctly handling time. Unfortunately, most of today’s methodologies and tools lack a consistent and verifiable handling of time – and are thus only of limited use for developing and verifying time-sensitive software.

Figure 2 is an attempt at a conceptual end-to-end architecture for time-sensitive software. Please note that this first sketch is a conceptual proposal and leaves open points for future research.

Figure 2. Layered architecture proposal.

Figure 2 proposes six architecture layers, each one with formal constructs to handle time explicitly:

The specification, modeling and verification layer (Top layer): For this layer, a process algebra is used. Process algebra is a formal calculus for specifying, modeling and verifying transition processes (DeNicola, Reference DeNicola2011; Aldini et al., Reference Aldini, Bernardo and Corradini2009; Fokkink, Reference Fokkink1999; Chao, Reference Chao2015). Some process algebras include the formal constructs for timing (e.g., Baeten and Middelburg, Reference Baeten, Middelburg, Bergstra, Ponse and Smolka2001, Reference Baeten and Middelburg2002; Wang, Reference Wang2002; Wolf, Reference Wolf2002);

The system architecture layer: Describes the parts (= components), their composition (= structure) and their relationships (= interactions). As a composition model, “Petri Nets for Modeling of Large Discrete Systems” (Davidrajuh, Reference Davidrajuh2021) is utilized;

The software architecture layer: As the component model providing the functionality, “Petri Modules” and “Inter-modular connectors” (IMC) (Davidrajuh, Reference Davidrajuh2021) are selected. The Petri modules are enriched with timing constructs (Popova-Zeugmann, Reference Popova-Zeugmann2016; Liu, Reference Liu2022);

The execution infrastructure layer: All software runs on the execution infrastructure layer. This layer encompasses all hardware, software systems and communication elements. Again, an execution infrastructure that is time-aware, that is, can provide execution timing guarantees, must be provided. The infrastructure of choice is the “Time-Triggered Communications” (TTC) (Obermaisser, Reference Obermaisser2012; Kopetz and Steiner, Reference Kopetz and Steiner2022; Kopetz and Bauer, Reference Kopetz and Bauer2003; Maier et al., Reference Maier, Bauer, Stoger and Poledna2002; Rushby, Reference Rushby2005; Buttazzo, Reference Buttazzo2023);

In addition, two transformation layers are required. Transformation Layer A translates the verified specification model into the Petri Net specifications. Note that the system architecture (Petri Net structure) is designed before the transformation A. Transformation layer B maps the timed functionality of the Petri Nets to the TTA schedule, that is, to the execution infrastructure.

Concurrency and latency

The two most challenging topics in implementing time-critical CPS are concurrency (e.g., Gorrieri and Versari, Reference Gorrieri and Versari2015) and latency (e.g., Kopetz and Steiner, Reference Kopetz and Steiner2022). In a modern CPS, many applications share common resources, such as CPUs, memory, external storage and communications channels, that is, parallel access to shared resources (Figure 3). This concurrency may result in one application or process influencing the timing of another application or process, sometimes adversarially, such that timing requirements may be violated, such as response times prolongated! If concurrency is not handled correctly, non-determinism can occur – delivering different results from a program run because of interference by concurrency (Gorrieri and Versari, Reference Gorrieri and Versari2015).

Figure 3. Concurrency and latency in a computing system.

The second topic is latency (Figure 3): In a classical architecture implementation, there are many sources of latency: Operating system functions, scheduling, communications delays, shared memory access retardation, queuing and so on. Some of these delays may be unpredictable and can behave statistically. For dependable time-sensitive software, concurrency and latency must be identified, quantified and adequately managed. The proposed architecture in Figure 2 is designed to strongly support this objective.

Process algebra

Context: For the specification, verification and modeling of the time-aware functional processes in the system (Top level layer of Figure 2), the methodology of Process Algebras with Time is chosen (e.g., Baeten and Middelburg, Reference Baeten, Middelburg, Bergstra, Ponse and Smolka2001, Reference Baeten and Middelburg2002; Wang, Reference Wang2002). Process algebras are formalisms for specifying interactions (synchronization, flow control, semaphores and so on) between concurrent processes. Modern process algebras evolved from the idea of formalizing communicating processes. The seminal contribution is the paper “A Calculus of Communicating Systems (CSS)” (Milner, Reference Milner1980). In the following years, several new Process Algebras were developed (e.g., Baeten, Reference Baeten2005; Bergstra and Klop, Reference Bergstra and Klop1984; Hoare, Reference Hoare1985). The early process algebras had no explicit and formal notion of timing. Timing was introduced later (e.g., Nicollin and Sifakis, Reference Nicollin and Sifakis1991). Today, process algebras with fully formalized timing exist (e.g., Baeten and Middelburg, Reference Baeten, Middelburg, Bergstra, Ponse and Smolka2001, Reference Baeten and Middelburg2002; Wang, Reference Wang2002). A process algebra defines a set of operators for the interaction of concurrent processes. A process algebra with time has additional operators for formally handling time.

Many process algebras with rich literature are in use today (e.g., Aceto, Reference Aceto2003). So far, no favorite, widely accepted and used process algebra exists. Process algebras are selected for the task at hand. For the widespread use of process algebras in industry, standardization by an industry body would be highly beneficial. A first attempt is the ISO standardization of a process algebra for communication protocols (Bolognesi and Brinksma, Reference Bolognesi and Brinksma1968; ISO, 2001).

Transition processes

Context: Process algebras require modeling the functionality of processes as transition systems (e.g., Demri et al., Reference Demri, Goranko and Lange2016; Gorrieri and Versari, Reference Gorrieri and Versari2015).

Transition systems have states. An action triggers the transition from one state to another. States and actions include explicit timing requirements in their specifications (Figure 4a, the symbol represents the timing). The theory of state machines is well-known and provides sufficient formality (e.g., Börger and Stärk, Reference Börger and Stärk2013).

Figure 4. Transition systems.

Figure 4b shows the example of a vending machine that is often used as a (much simplified) transition system. It has five states: Q₁ (= «Waiting for coin»), Q₂ (= «Waiting selection»), Q₃ (= «Coffee»), Q₄ (= «Tea») and Q₅ (= «Error»). The transitions are represented by arrows, including time-out after coin insertion and pressing both buttons simultaneously.

Timed Petri modules and inter-modular connectors

Context: Several realizations of the Petri Net idea exist. The one best suited for this architecture has been developed by Reggie Davidrajuh (https://www.davidrajuh.net/reggie/). It is applicable to large discrete systems and allows arbitrary system structures.

The functionality and quality properties of the system are implemented using “Timed Petri Modules” (Popova-Zeugmann, Reference Popova-Zeugmann2016; Wang, Reference Wang1998) and “Inter-Modular Connectors” (Davidrajuh, Reference Davidrajuh2021, Figure 5).

Figure 5. Timed Petri modules and inter-modular connectors.

The Timed Petri Modules feature all the constructs and properties of Petri Modules with time (e.g., Girault and Valk, Reference Girault and Valk2010). They implement the functionality and data. The interconnections of the Petri Modules specified by the process algebra are implemented by the IMC. These two building blocks give the architecture designer a high level of flexibility and allow any structure (not only hierarchical) to be defined.

The process algebra does not specify the system architecture. The distribution of functionality to the individual Petri Modules (Partitioning, cohesion and coherence and so on), the coupling of the Petri Modules by the IMC (Interfaces, loose coupling and so on) must be designed by a specialized system/software architect. Fortunately, proven, well-documented architecture principles and patterns (Figure 6) are available to construct a dependable, maintainable and evolvable architecture (e.g., Murer et al., Reference Murer, Bonati and Furrer2014; Furrer, Reference Furrer2019, Reference Furrer2022, Transformation Layer A below).

Figure 6. Software architecture.

Transformation Layer A

Context: While the four functional layers in Figure 6 use well-known, well-documented and proven technologies (Such as transition processes, process algebras, timed Petri Nets, the IMC composition model and TTCs, the two transformation layers are new concepts. The transformation layer A maps a timed transition system onto a timed Modular Petri Net. Although some literature exists on this specific topic (e.g., Badouel et al., Reference Badouel, Bernardinello, Darondeau, Badouel, Bernardinello and Darondeau2015; Devillers et al., Reference Devillers and Tredup2022; Best et al., 2024; Cortadella et al., Reference Cortadella, Lavagno, Kishinevsky and Yakovlev1995; Goltz, Reference Goltz and Guessarian1990), this transformation layer becomes a research topic – especially concerning timing implementation.

The transformation layer A has two transformation paths (Figure 7):

Figure 7. Elements of the Transformation Layer A.

Transformation Path 1 (Architecture, Figure 7):

The structural organization of the modular Petri Nets is of the highest importance, that is, strict adherence to proven architectural principles, such as modularization, correct partitioning (respecting cohesion and coherence), loose coupling and separation of concerns (e.g., Furrer, Reference Furrer2019; Platzer, Reference Platzer2018). This design of the adequate structure is independent of the formal specification of the system and must be carried out by very experienced software architects. Transformation path A requires a strong architecture governance in the IT organization (e.g., Murer et al., Reference Murer, Bonati and Furrer2014; Bell, Reference Bell2023). Once the Petri Modules/IMC structural architecture has been defined, the states and transitions that are to be encapsulated by each Petri Module are selected (Figure 7). Once all states, transitions and quality properties are transferred from the timed transition system to the timed Petri Module system, the duty of transformation path 1 is completed. Today, transformation Path 1 is state-of-the-art in methodology and architecture knowledge.

Transformation Path 2 (Timing, Figure 7 ):

Timed transition systems (e.g., Furia et al., Reference Furia, Mandrioli, Morzenti and Ross2012, chapters 7.3 & 7.4; Henzinger et al., Reference Henzinger, Manna and Pnueli1991; Hale et al., Reference Hale, Cardell-Oliver and Herbert1994) and timed Petri Nets have different formal notations for time representation (e.g., Furia et al., Reference Furia, Mandrioli, Morzenti and Ross2012, chapter 8; Wang, Reference Wang1998; Penczek and Pólrola, 2006). These different notations have differing expressiveness, and suitable notations must be selected for this application.

The transformation path 2 transcribes the transition system timing information to the Petri Net timing information (e.g., Best et al., Reference Best, Devillers, Koutny, Reisig and Rozenberg1998), including all constraints. Promising initial work has been done on such transformations (e.g., Khomenko et al., Reference Khomenko, Koutny and Yakovlev2022; Huang et al., Reference Huang, Jiao, Cheung and Wak2012), but more consolidating research is needed for this transformation path, focused on the proposed architecture.

Transformation Layer B

Context: The responsibility of the transformation layer B is to select one or more Petri Modules and use them to form a task (Figure 8). This includes correctly transforming not only the functionality and data, but also the timing and the quality properties.

Figure 8. Elements of the Transformation Layer B.

The transformation layer B has two transformation paths (Figure 8):

Transformation path 3 (Architecture):

Transformation path 3 selects one or several coherent Petri Modules, allocates them to specific tasks and uses the IMCs to define the relationships from task to task and from task to the environment. While the adequate architecture (structure, relationships) has already been defined by transformation path 1, the transfer of functionality/data/relationships/quality attributes from the Petri Module system to the task universe by the transformation path 3 must at least preserve – preferably improve – the quality of the software architecture. This means, again, strict adherence to proven architectural principles and patterns, such as modularization, correct partitioning (respecting cohesion and coherence), loose coupling and separation of concerns and so on. (e.g., Furrer, Reference Furrer2019; Richards and Ford, Reference Richards and Ford2025; Martin, Reference Martin2017; Cervantes, Reference Cervantes and Kazman2024; Khononov, Reference Khononov2025; Fettke and Reisig, 2022). Once all Petri Modules/IMC are transferred to the task structure, the duty of transformation path 3 is completed. Today, transformation Path 3 is state-of-the-art in terms of both methodology and architecture knowledge.

Transformation path 4 (Timing):

Transformation path 4 transfers the timing specifications from the Petri Net module system to the task universe, that is, to the implementation level. Timing in Petri Nets is introduced associated with places, transitions or both. Some work has been done on software implementations of timed Petri Nets (e.g., Girault and Valk, Reference Girault and Valk2010, Chapters 20 & 21; Ferscha, Reference Ferscha1994; Barad, Reference Barad2016; Moreno and Salcedo, Reference Moreno and Salcedo2006; Andrezejwski, Reference Andrezejwski2001). However, neither approach is sufficient for the application to the transformation path 4. Therefore, transformation Path 4 needs more research, specifically directed to the proposed architecture.

… and one feedback path (Timing adjustments): Timing Feedback:

The applications prescribe the timing requirements for the system (Processes in Figure 1). At the moment of timing specification, there is no guarantee that their successful implementation will be feasible (e.g., Klemm and Cownie, Reference Klemm and Cownie2021; Philippou and Sokolsky, 2007). The following obstacles may appear:

• Some tasks may have an unexpectedly large WCET;

• The task system is not schedulable (TTA);

• The physical communications channel’s transmission times negatively impact timing;

• The system does not provide sufficient resources to handle concurrency and latency;

• Correct error and fault handling require more resources than expected; and so on.

If the timing cannot be implemented in the real CPS, three resorts are possible:

1. I. Weaken the initial timing requirements (if the applications/processes allow it);

2. II. Try to modify the architecture (Structure, relationships);

3. III. Provide more implementation resources.

Once the complete system of timed Petri Net modules has been transferred into tasks and their relationships and the feasibility of the implementation has been assured, the mission of transformation layer B is complete.

Time-Triggered Protocol (TTP) – Time-Triggered Architecture (TTA)

The time-triggered architecture (TTA) defines a fault-tolerant execution platform for large, distributed, embedded real-time systems in mission- and safety-critical cyber-physical applications, such as avionics (e.g., Fuhrmann et al., Reference Fuhrmann, von Hanxleden, Rennhack and Koch2006). It is based on the time-triggered model of computation (Kopetz, Reference Kopetz1998; Kopetz, Reference Kopetz2017) and introduces the paradigm of TTCs (e.g., Kopetz and Bauer, Reference Kopetz and Bauer2003; Obermaisser, Reference Obermaisser2012; Kopetz and Steiner, Reference Kopetz and Steiner2022; Maier et al., Reference Maier, Bauer, Stoger and Poledna2002; Rushby, Reference Rushby2005; Buttazzo, Reference Buttazzo2023). The basic concepts of TTA are shown in Figure 10. Note that the TTC is a paradigm for electronic information exchange (as opposed to the event-triggered communications), TTP is the implementation and the TTA includes in addition system components, such as scheduler, redundant communication channel, global time synchronization and so on (Figure 10).

Figure 9. Transformation layers and runtime system.

Figure 10. Time-triggered architecture.

The Figure 10 introduces the following elements (From lowest to highest):

1. (1) A redundant communication bus that allows the exchange of messages. Initially, Time Division Multiple Access (TDMA)-scheme was used in the TTP. Later – forced by industry standardization – TTP was implemented on top of more communication schemes, such as Control Area Network (CAN) (Führer et al., Reference Führer, Müller, Dieterle, Hartwich, Hugel and Walther2000), Ethernet (Kopetz et al., Reference Kopetz, Ademaj, Grillinger and Steinhammer2005) and FlexRay (Shaw and Jackman, Reference Shaw and Jackman2008);

2. (2) TTP, managing the exchange of messages between the N nodes in the network, are implemented on top of the two communication channels, providing the necessary redundancy for safe operation. TTP provides fault-tolerant message transport with a fixed schedule at known times and minimal jitter by employing a TDMA (= Time-Division Multiple Access) strategy;

3. (3) A protocol to establish a global, synchronized time in all the nodes. TTA provides system-wide, fault-tolerant and distributed clock synchronization, establishing a global time base without relying on a central time server.

4. (4) The runtime systems in each node, that is, a set of tasks governed by a scheduler.

5. (5) Several algorithms for system functions (Obermaisser, Reference Obermaisser2012, Chapter 4):

   1. a. Clock synchronization,

   2. b. Startup and Restart,

   3. c. Diagnostic Services,

   4. d. Error Detection and Fault Isolation,

   5. e. Configuration Service,

   6. f. Schedule Generation and Schedulability Analysis

6. (6) The interfaces for the interaction of the tasks with the physical world (Sensors, Actuators).

The TTP is a deterministic, verifiable, well-analyzed message exchange scheme for fault-tolerant, distributed systems (e.g., Rushby, Reference Rushby2002). Therefore, it forms a predictable foundation for the execution platform in Figure 6.

Worst-Case Execution Time (WCET)

Each program (= a piece of code) has a worst-case execution time (WCET, e.g., Lokuciejewski, Reference Lokuciejewski and Marwedel2011). The WCET of a program is the maximum amount of time the program could take to execute on a specific execution platform, that is, the longest path through the program. Unfortunately, the WCET determination corresponds to the halting problem and is therefore not generally solvable. Estimation methods, such as simulation and code analysis (e.g., Franke, Reference Franke2016; Ferdinand and Heckmann, Reference Ferdinand and Heckmann2004), must be used to obtain valuable results. For time-sensitive software, the WCET of each program/module/task must be determined with sufficient accuracy (e.g., Wolf, Reference Wolf2002).

Runtime system and task scheduling

The resulting runtime system is shown in Figure 9. It consists of a set of tasks, system- and communications software, a computing platform (today often a cached, multicore CPU), the TTC bus and a task scheduler. The scheduler orchestrates the sequence of execution of the tasks in the distributed nodes of the system.

Except for the scheduling, all elements of the conceptual architecture in Figure 6 have been chosen due to the predictability and verifiability of their correct timing behavior. Scheduling, preemption and resource sharing may cause timing uncertainties and must be analyzed and implemented very carefully. A rich literature related to building, verifying and operating predictable, hard real-time computing platforms exists (e.g., Buttazzo, Reference Buttazzo2023; Gliwa, Reference Gliwa2022; Obermaisser, Reference Obermaisser2012 [Chapter 15]; Ayman et al., 2009; Antolak et al., Reference Antolak and Pulka2023). There is no space to handle this topic, only to raise awareness.

CPSs need global time, that is, a system-wide, precise and synchronized common physical time scale in all elements of the CPS (Shrivastava et al., Reference Shrivastava, Derler, Baboud, Stanton, Khayatian, Andrade, Weiss, Eidson and Chandhoke2016; Broman et al., Reference Broman, Derler and Eidson2013; Rajeev et al., Reference Rajeev, Mohalik and Ramesh2012). In the conceptual architecture of Figure 2, the TTA provides the global clock (Figure 10; Obermaisser, Reference Obermaisser2012, Chapter 4).

Mixed-criticality systems

Many CPSs are “mixed-criticality systems,” that is, they contain time-sensitive processes/parts and non-time-sensitive processes/parts. The system design must be based on solid partitioning and loose, monitored coupling between the two criticality regions.

Timing verification

The final truth of timing correctness lies in the runtime system (Lowest layer in Figure 6). Only if the runtime system strictly adheres to all timing specifications in all operating conditions can it be qualified as safe. The strong formalism and model-checking capabilities of the 3 top layers in Figure 6 ensure high confidence in the system timing conformance with the specifications because of the formal verification. Process algebras, transition systems and Petri Nets allow the verification of their timing properties (e.g., Becker, Reference Becker2020; Willemse, Reference Willemse2003; Camargo, Reference Camargo1998; Corradini et al., Reference Corradini, D’Ortenzio and Inverardi1999; Philippou and Sokolsky, 2007; Penczek and Pólrola, 2006; Wolf, Reference Wolf2002).

Timing verification on the lowest layer in Figure 6 (Runtime system) requires measurements, tracing, statistics, analysis and assessment (e.g., Rohr, Reference Rohr2015; Becker, Reference Becker2020). Runtime verification, especially for the timing, is a challenging task but sufficiently researched (e.g., Colombo and Pace, 2022).

Real-Time Calculus (RTC)

A promising development for formalizing the timing behavior and formal verification of the runtime system is the RTC (e.g., Guan, Reference Guan2018; Thiele et al., Reference Thiele, Chakraborty and Naedele2000; Two Examples in: Chokshi and Bhaduri, Reference Chokshi and Bhaduri2010; Bazzal et al., Reference Bazzal, Krawczyk, Govindarajan and Wolff2020). The key concept in RTC is the Greedy Processing Component (GPC, Figure 11). The GPC accepts input events, launches the appropriate processing and outputs the processed event stream. The event streams are formalized by arrival curves based on the number of events arriving at an interval (one for the lower bound, the other for the upper bound). The resources consumed to process the input events are also formalized by service curves based on the amount of resources consumed in an interval Δ, one for the lower bound, the other for the upper bound.

Figure 11. RTC key concept – Greedy Processing Component (GPC).

For the arrival and service curves, operators are defined to build compositions of GPCs and thus describe systems of arbitrary complexity. The benefits of the RTC include the formalism for determining bounds for execution, communication, queues and buffer sizes. Additionally, the schedulability of multitasking software systems can be determined using RTC.

Runtime monitoring

As a last defense against timing violations, runtime monitoring can be used. Whereas runtime verification aims to check specific parameters of the program execution, such as the execution times of a set of tasks, runtime monitoring supervises the system in order to detect anomalous or dangerous behavior. If anomalous behavior is detected, the system may automatically take protective actions, thus trying to avoid safety accidents or security incidents. Machine learning algorithms are often used for anomaly detection. (e.g., Furrer, Reference Furrer2023).

Open questions and future work

• Develop a complete and consistent metamodel to ensure the conceptual integrity of all layers in Figure 2 (e.g., Gonzalez-Perez and Henderson-Sellers, Reference Gonzalez-Perez and Henderson-Sellers2008)

• Choose and agree on a semantic and notation for a suitably timed process algebra. Codify it as an industry standard;

• Choose and agree on a semantic and notation for timed transition systems. Propose it as an industry standard;

• Choose and agree on a semantic and notation for a timed Petri Nets (Preferably based on Davidrajuh, Reference Davidrajuh2021). Propose it as an industry standard;

• Develop, discuss and document a modeling methodology for systems based on Figure 6 (Metamodel, notation, semantics, graphical representation and so on);

• Define a methodology, principles and metrics for the transformation layer A;

• Define a methodology, principles and metrics for the transformation layer B;

• Integrate the formalism of RTC into the architecture of Figure 6;

• Investigate the applicability of the (possibly extended) conceptual architecture of Figure 2 to continuous and hybrid CPSs (e.g., David et al. and Alla, Reference David and Alla2010; Gu and Dong, Reference Gu and Dong2005; Bera et al., Reference Bera, Van Hee and Nijmeijer2014);

• Demonstrate the capability of the conceptual architecture (Figure 2) for closed-loop CPS (e.g., Pasandideh et al., Reference Pasandideh, Gomes and Maló2022; Núñez-Alvarez et al., Reference Núñez-Alvarez, Benítez-Pina, Acosta-Montoya, Pino-Escalona and Villafuela-Loperena2023);

• Does the conceptual architecture (Figure 2) have the capability to generate the most efficient solution regarding resources? (Rodriguez et al., Reference Rodriguez, Julvez and Merseguer2013; Jarabo, Reference Jarabo, Gómez-Martínez, Kallwies, Haustein, Leucker, Stolz and Stünkel2024; Shi et al., Reference Shi, He, Gu, Ran and Ma2023); How?

• Is adding more resources until timing constraints can be satisfied always feasible?