DRS Slidedeck FHTW

Administration

• Part 0: Administration

Motivation for Good System Design

• Catastrophic Events in the Past (with links to examples):
  • Ariane 5 failure: Software integration and error handling issue.
  • Therac-25 radiation treatment machine: Failures due to software and hardware design faults, leading to patient deaths.
  • Patriot system failure.
  • Three Mile Island: Partly caused by bad design of distributed real-time systems.

Introduction

• About the Instructor:
  • 1994-1998: Assistant at the Institut für Technische Informatik, TU Wien; worked on the TTP/C time-triggered communication system.
  • 1998: Doctorate at the Institut für Technische Informatik, TU Wien.
  • 1999-2007: CTO of DECOMSYS GmbH, automobile industry; co-developed FlexRay and AUTOSAR standards.
  • 2008-2011: Consulting in functional safety in the automotive industry.
  • Since 2011: Co-owner of TWINGZ Development GmbH, focusing on damage prevention in buildings and industrial plants.
  • 2018: Established AI Austria.
  • 2019: Designed the KI Akademie of WIFI NÖ.
  • 2024: Auditor at Austrian Standards.
  • Private interests: AI, Windsurfing, Running.

Organization

• Lecture Times: Tuesday, 17:50-21:00 (plus variations).
• Seminar: Presentation (15 minutes) + slides to share by each student.
• Hands-on Units: Building a distributed real-time system together as one team via Internet.
• Exam: Online, multiple-choice questions (typically 40).
• Grade: Integrated (Gesamtnote).

Materials

• Slides: PDF format, links available on Moodle.
• Book: Hermann Kopetz, Real-Time Systems – Design Principles for Distributed Embedded Applications, Kluwer 1997.

Lecture Content

• Content of Lecture
  • Distributed Systems and Time
  • Real-time Communication and Execution
  • Fault-Tolerance
  • Design Patterns (Time permitting)
  • Exercise: Includes a small lecture part about systems integration.

Seminar Topics

• Seminar Topics:
  1. EtherCat
  2. Clock synchronization of GPS OR IEEE 1588
  3. Software Safety Standards OR System Safety (Nancy Leveson)
  4. Software-triggered catastrophes and their root causes (Ariane 5)
  5. Architectures in automobiles OR AUTOSAR
  6. Intelligent Sensor systems
  7. Industrial real-time system software and communication systems
  8. Architectures in Airplanes OR Spacecrafts
  9. Control systems of nuclear power plants
  10. Soft real-time distributed vs hard real-time distributed systems
  11. Choose your own topic

Content of Hands-On Part

• Distributed Real-Time System based on Raspberry Pi and Ethernet (or better).
• Team development of a complete system with different roles.

Distributed Systems

• Different scales, same principles, from mm to 1,000s of kms

Complexity

• The slide shows a system complexity map of a car, illustrating interdependencies between subsystems.
• Complexity Measures:
  • Global complexity measure
  • Critical = $11.11$
  • Current = $9.51$
  • Minimum = $4.54$
  • Robustness = $65.28$

Example: Paper Mill

• Machine Cluster (EtherCat)
• Cutter Cluster (PowerLink)
• Factory Cluster (Ethernet)
• Company ERP (SDL GW)

What is a Distributed System?

• Definition: Two connected systems separated by a physical gap, requiring an explicit communication link.
• Characteristics:
  • Significant delay compared to communication inside nodes.
  • Higher error rate than communication inside nodes.
• Nodes A and B connected via a link across a physical gap.

Reasons for Distribution

• Arguments to build hard real-time systems as distributed solutions:
  1. Reduction of complexity
  2. Scalability
  3. Cost
  4. Dependability
• From a functional point of view, it makes little difference whether a given specification is implemented using a centralized architecture or a distributed architecture.

Complexity

• Managing Complexity:
  • Large systems require controlled complexity to ensure understanding and manageable operation as the system grows.
  • Inner behavior of subsystems should be encapsulated behind stable and simple interfaces.
• Key mechanisms for complexity control:
  1. Partitioning of a system into subsystems
  2. Encapsulation of the subsystem
  3. Preservation of the abstractions in case of faults
  4. Strict control over the interaction patterns among the subsystems

Scalability

• Scalability:
  • A scalable architecture is open to changes and doesn't limit a system's extensibility.
  • Distributed systems are generally more scalable than centralized systems.
  • A scalable architecture should not have central bottlenecks in processing or communication.
• Advantages of distributed architectures:
  1. Nodes can be added (within communication channel capacity) for additional processing power.
  2. A node can become a gateway to a new cluster if communication capacity is fully utilized within a cluster.

Cost

• Cost Considerations:
  • Centralized systems may offer short-term cost advantages but can lead to long-term disadvantages as system size increases.
• Cost advantages of distributed systems:
  1. Reduced cost of scaling and extension
  2. Reduced maintenance costs (replace nodes vs. entire system)
  3. Reduced certification costs

Dependability

• Dependability in Distributed Systems:
  • Fault-tolerant systems must be structured into partitions that act as error-containment regions.
  • Consequences of faults in one partition should be detectable, correctable, or maskable before corrupting the rest of the system.
  • Error containment is generally easier to achieve in distributed systems than in centralized ones.

Replication

• Replication for Fault-Tolerance:
  • Fault-tolerance requires redundant units in a system.
  • Distributed systems offer a clear solution for redundancy: a node can represent a unit of failure (error containment region).
  • Goal: Map all inner failure modes of a node into a single external failure mode, such as fail-silence.
  • If the failure hypothesis holds, node failures can be masked by providing actively replicated (redundant) nodes.

Certification

• Certification of Safety-Critical Systems:
  • Safety-critical systems often require approval by an independent certification agency.
  • Assessment is based on the safety case presented by the designer.
  • A safety case is an accumulation of credible analytic and experimental evidence that the system is safe to deploy.
  • Distributed systems with less complex interactions via interfaces are easier to certify than centralized systems with many complex interactions.

Critical vs. Non-Critical Functions

• Mixed Criticality Systems:
  • Commercial systems often require operating critical and non-critical functions in one system.
  • It's crucial to design an architecture that prevents unintended interference between subsystems of differing criticality.
  • A distributed architecture offers a way to separate non-critical functions from critical functions by establishing error containment and using composability arguments.

Separation of Suppliers

• Supplier Ecosystem:
  • OEMs in some industries rely on a supplier ecosystem for vital system components (e.g., in the automotive industry).
  • Distributed systems enable easier assignment of parts to different suppliers.
  • This is more challenging in centralized systems.

Real-Time Computer Systems

• Real-Time Computer Systems Definition:
  • Correctness depends not only on correct output and input values but also on the timing of these values.

Deadlines

• Deadlines in Real-Time Systems:
  • Deadline: A real-time computer system must react to stimuli from the controlled object within specific time intervals dictated by the environment.
  • Soft Deadline: Utility remains even after the deadline has passed.
  • Firm Deadline: Catastrophe could result after a firm deadline is missed, hard deadline.
  • Hard Real-Time Systems: Must sustain guaranteed temporal behavior under all specified load and fault conditions.
  • Soft Real-Time Systems: Tolerate occasional deadline misses.

Hard-RT vs Soft-RT

• Comparison Table: Hard RT vs. Soft RT Characteristics
  • Response Time:
    • Hard RT: Must be guaranteed
    • Soft RT: Best effort
  • Peak-load performance:
    • Hard RT: Predictable
    • Soft RT: Degraded
  • Control of pace:
    • Hard RT: Controlled object
    • Soft RT: Computer
  • Size of data:
    • Hard RT: Small
    • Soft RT: Large
  • Redundancy:
    • Hard RT: Active
    • Soft RT: Standby, checkpoint recovery
  • Data integrity:
    • Hard RT: Short-term
    • Soft RT: Long-term
  • Error detection:
    • Hard RT: Autonomous
    • Soft RT: Non-autonomous

Resources

• Resource Management in Real-Time Systems:
  • Systems with firm or hard deadlines must have sufficient pre-allocated computing resources to handle specified peak load and fault scenarios.
  • Soft real-time systems may use dynamic resource allocation strategies based on resource sharing and probabilistic arguments.
• Computing resources examples:
  1. Random access memory (heap and stack)
  2. CPU processing capacity
  3. Communication bandwidth
  4. I/O bandwidth

Trigger of Action

• Event-Triggered Approach:
  • Communication and processing activities are initiated upon significant state changes.
  • Signaling is realized by an interrupt mechanism
  • Dynamic scheduling is used to activate appropriate tasks
• Time-Triggered Approach:
  • Activities are initiated at predetermined points in time based on a local clock.
  • Local clocks of all nodes are synchronized

Classification of RT Systems

• Classification of Real-Time Systems:
  1. Hard RT vs. Soft RT
  2. Guaranteed response vs. Best effort
  3. Resource adequate vs. Resource inadequate
  4. Event-triggered vs. Time-triggered
• Dependencies:
  • 1 & 2: depend on specific application requirements
  • 3 & 4: depend on the design and architecture of the system

Modelling Real-Time Systems

• Key Elements for Modeling Real-Time Systems:
  1. Load- / Fault-Hypothesis
  2. Structure
  3. Tasks
  4. Timing
  5. Transactions
  6. H-state, ground-state

Load- and Fault Hypothesis

• Important Assumptions in Designing Fault-Tolerant Real-Time Systems:
  • Load Hypothesis: Response time statements are valid only if the load is below a maximum (peak load).
    • Example: Define the maximum requests per second.
  • Fault Hypothesis: Assumptions about potential faults during system operation.
    • If actual faults exceed the fault hypothesis, even a perfectly designed fault-tolerant system will fail.
    • Example: Maximum of one component failure during mission time.

Structure

• Node Definition:
  • A node is a self-contained computer with its own hardware (processor, memory, communication interface, I/O) and software (application program, OS).
  • Performs well-defined functions within the distributed computer system.
• Node Importance:
  • It binds software and hardware resources into a single operational unit.
  • Has observable behavior in both temporal and value domains at its interfaces.
• Node hardware components:
  • Host computer
  • One or more communication network interfaces (CNI)
  • I/O interfaces

Structure and State of a Node

• Node Software Data Structures:
  1. Initialization state (i-state): Static data structure containing program code and initialization data; stored in ROM.
  2. History state (h-state): Dynamic data structure of the node; stored in RAM.
• H-State Initialization:
  • After node start, the h-state is empty and must be initialized from ROM or other redundant nodes.

Fault-Tolerant Unit

• Abstraction for Implementing Fault Tolerance by Active Replication.
• Composed of a set of replicated nodes that produce replica-determinate result messages (same results at approximately the same points in time).
• Each FTU consists of one or more node computers.
• Smallest Replaceable Unit (SRU):
  • In many cases, a node of a distributed computer system is the smallest replaceable unit that can be replaced in case of a fault.

Computational Cluster

• Definition: A fault-tolerant computational cluster comprises a set of FTUs that work together to provide a fault-tolerant service for the cluster environment.
• Interfaces between cluster and environment:
  • Formed by the gateway nodes of the cluster
  • I/O of the nodes

Interfaces

• Importance: Layout and placement of interfaces are the most important activity in design, as architecture design is primarily interface design.
• Interface Definition: A common boundary between two subsystems that provides understandable abstractions to the interfacing partners.
• Interface Characterization:
  1. Control properties: Characteristics of control signals crossing the interface (e.g., interrupts, chip-select).
  2. Temporal properties: Temporal constraints that must be satisfied by the control signals.
  3. Functional intent: Specification of the intended functions of the interfacing partners.
  4. Data properties: Structure/semantics of data, bit ordering.

Temporal Obligations

• Temporal Parameters in a Client-Server Model:
  1. Maximum response time $dRESP$ expected by the client
  2. Actual worst-case execution time $dWCET$ of the server
  3. Minimum allowed time $dMINT$ between two requests
  4. Minimum response time $dRESPMIN$ of the server
• Control Sphere:
  • $dWCET$ is within the server's control
  • $dMINT$ is within the client's control
• Hard Real-Time Guarantee: Implementation must ensure that dWCET < dRESP under the condition that $dMINT$ is maintained between requests.

Actions

• Actions in Real-Time Systems:
  • All activities in a real-time system can be seen as actions, taking place at every system level.
• Typical actions in a real-time system model:
  • Tasks: Execution of code in a node CPU
  • Communication: Transfer of information between nodes
  • I/O: Transfer of information between environment and node

Duration of Actions

• Four quantities describe the temporal behavior of an action a (e.g. task):
  1. Actual duration (actual execution time) $dact(a,x)$
  2. Minimal duration $dmin(a)$: Smallest time interval it takes to complete action a
  3. Worst-case execution time (WCET) $dWCET(a)$: Is the maximum duration it may take to complete the action a under the assumed load and fault hypothesis and under all possible input data
  4. Jitter: $dWCET(a) - dmin(a)$: jitter has negative impact on control systems

Action Duration Statistics

• Action Duration Statistics
• Notes:
  • $dWCET$ is usually very pessimistic, only few runs will take $dWCET$.

Tasks

• Tasks
  • A Task is the execution of a sequential software program (action).
    • It begins with reading the input data and the internal state, and terminates with the production of the results and updating the internal state.
• Task Types
  • Stateless Task: A task that does not have an internal state at its point of invocation.
  • Task with State: A task that maintains an internal state.
• S-Task vs. C-Task
  • Simple Task (S-task): If there is no synchronization point within a task, we call it a simple task (S-task). i.e., whenever an S-task is started, it can continue until its termination point is reached. Because a S-task can not be blocked, the execution time of the task is not dependent on others tasks of the node, and can be determined in isolation.
  • Complex Task (C-task): A task is called a complex task (C-task) if it contains a blocking synchronization statement (e.g., a semaphore operation “wait”) within the task body. The WCET of a C-task is determined outside the control of the task and thus much harder to calculate.

Control of Action

• Logical Control:
  • Deals with the control flow within a task, determined by the program structure and input data, to achieve the desired data transformation.
• Temporal Control:
  • Deals with determining the points in time when a task must be activated or blocked based on external conditions.
• S-Task Temporal Control: Only issue is determining when the task must be activated; once activated, it runs to completion within its WCET.
• C-Task: Blends issues of logical control with temporal control.

Interrupts

• Interrupts:
  • An interrupt is an asynchronous, hardware-supported request for a specific task activation caused by an external event to the currently active computation.
  • Context switches for an interrupt require a worst-case administrative overhead, WCAO.
• Impact of Interrupts:
  • Every interrupt reduces available CPU activity by the size of WCAO.
  • The frequency of interrupts must be limited; if it reaches 1/WCAO, no CPU capacity remains.
  • This requires additional protection mechanisms because the interrupt source is outside the node's control.

Worst Case Execution Time

• WCET:
  • A deadline for completing an RT transaction can only be guaranteed if the worst-case execution time (WCET) of all the application tasks that are part of the transaction are known a priori.
• WCET of an S-task depends on:
  1. Source Code:
     • Restrictions for a real-time program: no unbounded controls statements, no recursive function calls, and no dynamic data structures.
     • WCET analysis must determine the program path executed in the worst-case scenario (critical path).
  2. Compiler Analysis:
     • Determination of the maximum execution time of basic language constructs (timing tree).
  3. Microarchitecture Timing Analysis:
     • Determination of the worst-case execution time of target hardware commands (e.g., caches).

Preemptive S-Tasks

• Impact of Preemption on S-Task Execution Time:
  • If an S-task is preempted by another independent task, its execution time is extended by three terms:
    1. The WCET of the interrupting task
    2. The WCET of the context switch (operating system)
    3. The time required for reloading data and instruction caches in the microarchitecture
• Worst-Case Administrative Overhead (WCAO):
  • The sum of delays 2 and 3 is called Worst-Case Administrative Overhead (WCAO) of a task preemption.
• Microarchitecture Delays Significance:
  • In many applications, microarchitecture delays (3) can be the most significant terms because the WCET of the interrupting task is normally quite short.

WCET of Complex Tasks

• WCET of a C-task:
  • Depends not only on task performance but also on the behavior of other tasks and the operating system within a node.
  • WCET analysis is not a local problem but a global problem involving all interacting tasks within a node.
  • Impossible to calculate the WCET of a C-task without analyzing the temporal properties of the complete system of interacting tasks.

Transactions

• Transactions
  • Distributed functions can be described by transactions.
  • A transaction is a sequence of IO, processing (action, task) and communication (receive, transmit) operations.
  • Each transaction can be drawn as a directed graph leading from input via processing and communication to output.
  • The connection points as well as the action and communication operations in a transaction hold many properties which determine the resulting real-time behavior of the transaction.

Why Transactions?

• Modeling transactions in distributed real-time systems is essential because transactions represent the flow of data and actions (causality) within the system.
• A transaction consists of a sequence of I/O operations, processing tasks, and communication events, all of which must be correctly timed and executed to meet real-time constraints.
• By modeling transactions, engineers can:
  • develop suitable requirements
  • analyze and optimize system performance
  • ensure timing predictability
  • guarantee that critical deadlines are met
• In a project there should be persons responsible for transactions in order to maintain the consistent implementation of the transaction.
• Compared to classical per node responsibilities, this ensures that flow of data and actions is consistent.

H-State and Ground State

• H-State Definition:
  • The h-state at any point of interruption can be defined as the contents of the program counter and of all data structures that must be loaded into a “fresh” hardware device to continue operation at the point of operation.
  • The size of a h-state depends on the level of abstraction and on the observation time.
  • A small h-state eases the reintegration of a failed component.
• Ground State Definition:
  • The ground state of a node in a distributed system at a given level of abstraction is a state where no task is active and where all communication channels are flushed, i.e., there are no messages in transit.
  • At the ground state, the h-state is minimal.
  • Reintegration of a node after a failure is simplified if a node periodically visits a ground state that can be used as reintegration point.

Time and Order

• In a typical distributed real-time application, different functions are executed at different nodes.
• To guarantee the consistent behavior of the entire distributed system it sometimes must be ensured that all nodes process all events in the same consistent order in which the events occurred.
• A global time base helps to establish such a consistent temporal order on the basis of the timestamps of the events as well as time-coordinated action on the controlled object.

Message Sequence

• A: f, f, b, b is state D
• Message sequence 2: f, b, f, b → State A

Temporal Order, Event, Duration

• Modeling Time:
  • The continuum of real-time can be modeled by a directed timeline of instants {T}.
  • The order of instances on this timeline is the temporal order.
• Definitions:
  • Duration: A section of the timeline.
  • Event: Takes place at an instant of time and does not have a duration.
  • Simultaneous Events: If two events occur at an identical instant of time, they occur simultaneously.

Physical Clock

• Components of a Physical Clock:
  • A counter
  • A physical oscillation mechanism that periodically generates an event to increase the counter.
• Terminology:
  • Microtick: The periodic event generated by the oscillation mechanism.
  • Granularity: The duration between two consecutive microticks (digitization error in time measurements).

Reference Clock

• Hypothetical Observer:
  • Assume an external observer who can observe all events of interest.
• Reference Clock:
  • The observer possesses a unique reference clock z with frequency f in perfect agreement with the international standard time.
  • z is a model of time providing absolute timestamps for each event.

Clock Drift

• Clock Drift Definition:
  • The drift of a physical clock k between two microticks i and i+1 is the frequency ratio between this clock and the reference clock.
• Drift Rate Formula:
  k is the nominal tick count. Drift rate ρi k= | (z(microticki+1 k)-z(microticki k))/nk - 1|
  
• Perfect Clock: A perfect clock has a drift rate of 0.
• Typical Drift Rates: Vary from $10^{-2}$ to $10^{-7}$ sec/sec depending on resonator quality.

Offset Precision Accuracy

• Offset: Time difference between microticks of two clocks, measured in microticks of the reference clock.
• Precision: Maximum offset of microticks of any two clocks in the ensemble during the period of interest.
• Accuracy: Maximum offset of a given clock from the external time reference during the time interval of interest.

Synchronization

• Internal Synchronization:
  • Process of resynchronizing an ensemble to maintain a bounded precision, addressing clock drift.
• External Synchronization:
  • Process of periodically resynchronizing a clock with an external reference clock to keep it within a bounded interval of the reference clock.

Time Standards

• Relevant Time Bases for Distributed Real-Time Systems:
  • International Atomic Time (TAI)
  • Universal Time Coordinated (UTC)
• TAI:
  • Second derived from the period of the cesium atom 133.
  • Chronoscopic timescale without discontinuities.
• UTC:
  • Derived from astronomical observations of Earth's rotation relative to the Sun.
  • Not chronoscopic (e.g., leap seconds).

Global Time

• The Challenge of Perfect Synchronization:
  • Since each node has a local oscillator, tight clock synchronization is impossible.
• Global Time Concept:
  • An abstract notion approximated by properly selected microticks (e.g., each n-th microtick) from synchronized local physical clocks.
• Macrotick (Tick):
  • A selected local microtick from synchronized local physical clocks.
• Assumptions:
  • All clocks are internally synchronized with a given precision π.

Global Time and Macrotick

• macrotick = ticks of the global time
• granularity g of the global time
• π precision

Reasonableness Condition

• Condition for a Reasonable Global Time: g > \pi
• Ensuring Temporal Order Recovery:
  • Ensures that the offset between two local clocks (measured in microticks) is less than the macrotick duration.
  • Macrotick timestamps of an event captured by different nodes vary by a maximum of 1.
  • Temporal order of events can be recovered if the difference between timestamps is $≥ 2$ macroticks.

Limits of Time Measurement

• Limits of Time Measurement
  1. If a single event is observed by two different nodes, there is always a possibility that the timestamps differ by one tick – and a one tick difference is not sufficient to re-establish the temporal order of the events.
  2. If the observed duration of an interval is $dobs$, then the true duration $dtrue$ is bound by ($dobs - 2g$) < ($dtrue$) < ($dobs + 2g$) since a duration is bound by two events. For each event 1) is valid.
  3. The temporal order of events can be recovered from their timestamps, if the difference is $≥ 2$ ticks.

Internal Clock Synchronization

• Internal Clock Synchronization:
  • Objective: Ensure that global ticks of all correct nodes occur within a specified precision $\pi$despite varying drift rates of local real-time clocks.
• Importance of a Proper Global Time Base:
  • Crucial for the operation of a distributed real-time system; clock synchronization should be fault-tolerant.

Synchronization Condition

• Synchronization Parameters:
  • Resynchronization Interval ($R_{int}$): The period between resynchronization points.
  • Drift Offset ($\Gamma$): The maximum deviation between clocks due to drift, limited by the period of resynchronization.
  • Deviation After Synchronization ($\Phi$): The deviation between clocks immediately after synchronization.
• Synchronization Condition Formula: \Phi + \Gamma < \pi

Clock Synchronization Algorithms

• Central master: one node determines the clock tick of the cluster
• multi master: several nodes can be master. A switching mechanism is required. (e.g. Berkeley’s algorithm)
• distributed algorithms: many nodes of a cluster participate in the generation of the clock tick. (e.g. FlexRay)
• hierarchical algorithms: in a layered structure of clusters, nodes distribute the clock tick to lower levels (e.g. NTP)

Central Synchronization

• A master node periodically transmits its timestamps.
• Each receiver node calculates the deviation between the local time and the timestamp in the message minus the transmission duration as a correction value
• Each receiver applies the correction value to the local clock
• The precision of the algorithm is limited by the variation (jitter ε) of the transmission duration dT. πcentral >= ε + Γ
• Disadvantage is the missing fault-tolerance against failure of the central clock and drift of the central clock.

Latency Jitter

• Definition: Crucial Factor in Synchronization Precision:
  • Latency jitter ($\varepsilon$) of synchronization messages carries time values from one node to others in an ensemble.
• Example Jitter Ranges:
  • Application software level: 500$\mu$s to 5ms
  • Kernel of OS: 10$\mu$s to 100$\mu$s
  • Hardware of communication controller: < 10$\mu$s

Clock Correction

• State Correction:
  • Correction term is immediately applied to the local-time value, causing a discontinuity in the time base.
  • To avoid discontinuities, the state correction term can be split up and applied incrementally (e.g., one microtick per macrotick).
• Rate Correction:
  • The clock rate is modified so that the clock speeds up or slows down during the next resynchronization interval.
  • Example involves changing the divider value between microtick and macrotick.
  • Rate corrections must be carefully designed to prevent oscillations within the clock ensemble.

External Clock Synchronization

• External Synchronization
  • Links the global time of a cluster to an external time standard (e.g., GPS time, DCF time).
• Process
  • Access a time server, i.e., an external time source that periodically broadcasts the current reference time which is done by the synchronization gateway.
  • Handle the time message in the same way as a central master message.
  • If necessary, transform the external time to the cluster global time.

Real-Time Entities and Images

• Key Concepts:
  1. Real-Time Entity (discrete / continuous)
  2. Observations
  3. Real-Time Image / Object
  4. Temporal Accuracy
  5. Phase-Sensitivity
  6. Permanence

Real-Time Entity

• Definition: A state variable of relevance for the given purpose, located in the physical environment or the computer system (e.g., temperature, voltage, a variable in a computer).
• Attributes:
  • Static attributes: Do not change over time (e.g., name).
  • Dynamic attributes: Change with time (e.g., rate of change at a point in time).
• Control: Every RT entity is in the sphere of control of a subsystem; outside this, it can only be observed, not modified.

Observations, States and Events

• States can be observed
• an event cannot be observed, only the new state after a state change can be observed.
• every change of state is an event.

Observations

• Observation Definition: Atomic Triple
• Types of Observation:
  • Continuous RT Entity: Can be observed at any point in time.
  • Discrete RT Entity: Can only be observed between the Levent and the Revent.
• State vs Event Observation:
  • State Observation: Contains the absolute state of the RT entity at the time of sampling.
  • Event Observation: Contains information about the change of value between the “old state” and the “new state.”

Issues with Event Observations

• Difficulties of working with event observations
  1. Where do we get precise time of the event occurrence?
  2. An event observation contains the difference between old and new state – loss of state synchronization between observer and receiver is possible (e.g., loss of a single event observation).
  3. An event observation is only sent if the RT entity changes its value. The detection of node failures is more difficult since it cannot be distinguished if no event has happened, OR if the observing node has failed.

Temporal Model Overview

• $d_{update}$ - update delay - time between observation of RT entity and update of RT image with new value
• $d_{object}$ - controlled object delay - time after which state variable begins to rise, part of the physical process of controlled object
• $d_{rise}$ - rise time of step response - part of the physical process of controlled object
• $d_{processing}$ - processing duration - duration of computing a new input into a new output value
• $d<em>{sample}$ - sampling period - d{sample} << d{rise}. depending on control requirements (e.g. d{sample} < d_{rise} / 10)
• $d_{computer}$ - computer delay - time interval between the sampling point and the start of reaction of computer at output.
• $\Delta d<em>{computer}$ - jitter of computer delay - distorts quality of control algorithms. \Delta d{computer} << d_{computer}
• $d<em>{deadtime}$ - dead time - $d</em>{computer} + d_{object}$

Real-Time Computer Update Delay

• Real-time Computer Update Delay - Example with a motor
• $d_{update}$

Real-time Computer Processing Duration

• Real-time Computer Processing Duration - Example
• $d_{processing}$

drise and dobject

• drise and