TU Wien:Distributed Real-Time Systems Engineering VL (Kopetz)/Zusammenfassung der Papers fuer Einstiegstest

Definitionen

The Complexity Challenge in Embedded System Design

Model

A model is a deliberate simplification of reality with the objective of explaining a chosen property of reality that is relevant for a particular purpose.

Four Universe Model

4 Levels of abstraction when modeling a computer system.

• Physical Level (lowest): analog signals of the circuits (rise time, voltages, switching ops)
• Digital Logic Level: Abstracts from Physical, introduces binary logic values(high, low), AND, OR, ... gates
• Information Level: lumps a possibly large sequence of binary values into a meaningful data structure (pointer, ...)
• External Level (highest): services of the computer system to the enviroment, as seen by an outside observer are of relevance

Cognitive Complexity of a model

cognitive effort needed to understand the model. cognitive complexity depends on the relationship between the existing conceptual landscape in the client's mind versus the concepts deployed in the representation of the model, the interrelations among these concepts and the notation used to represent the concepts. Conceptual Landscape is the result of the client's life-long experience.

Concept Formation

A thorough concept formation is an essential prerequisite for any formal analysis or formal verification.

A new concept should have the following properties:

• Utility: useful well defined purpose
• Abstraction and Refinement: abstract from lower-level properties. clear what properties are not part of the concept. in case of refinement, it should be clear which additional aspects are considered
• Precision: precisely definition of the properties
• Identity: distinct identity for the new concept, significantly different from other concepts
• Stability: useable uniformly in many different contexts without any qualification or modification
• Analogy: similar concepts for better understanding should be pointed out

Association/Relation

An association is a link between a cue and an associate. Activation of the cue evokes the associate, but the reverse is not necessarily the case. A relation is a link between a relation-symbol or predicate, and one or more arguments. "Each argument constitutes a dimension in the space representated by the relation, and the number of arguments provides a metric for conceptual complexity."

in associations there is no symbol that represents the associative link. Persons can have associations without knowing that the link exists, so they know something but do not know that they know it.

an association is unidirectional, a relation is omni-directional.

Associations seem to be the main linking mechanism of concepts in unconscious mental processing, relations seem to be characteristic for explicit thought in higher cognitive processes.

Abstraction/Partitioning/Segmentation (Simplification Strategies)

• Abstraction: formation of higher-level concept by omitting irrelevant detail.
• Partitioning: Spatial division of problem into nearly independent parts. problems with emergent properties.
• Segmentation: Temporal decomposition of complex behavior into smaller parts for sequential processing. Reduces amount of information that has to be processed in parallel. Nearly impossible in concurrent systems.

Determinism

Determinism: A model behaves deterministically iff, given a full set of initial conditions (i-state) at time t0, and a sequence of future timed inputs, the outputs at any future instant t are entailed.

Determinism of behavior is closely related to the rational analysis of behavior, since determinism is a sufficient precondition for logical reasoning.

Failures

• design error in the software: hardware operates as in the model, deviation between observed and expected behavior
• design error in the hardware: divergence of hardware from hardware execution model
• physical hardware fault: hardware designed according to model and deviation is due to permanent or transient physical defect of the hardware

System must be partitioned into FTUs (Fault containment units). Errors must be detected on FTU-bounds to avoid error propagation to other not affected units (error containment principle). Error containment principle constrains the physical structure, the partitioning, of the evolving computing system.

Basic-level Concept

• A basic level concept is a key concept that is vital for achieving understanding in a given domain.
• Basic level concepts are used to reason about the behavior of component-based distributed embedded systems at the system level.
• For example: Component, Message, Sparse time, Cycle, State ..
• (Cycle + sparse time) concepts => time concept => state concept => Determinism

Message

Atomic data structure that is formed for the purpose of transmitting data and control signals from a sending component to one or more receiving component(s).

Sparse time

Continuum of real-time is partitioned into a sequence of alternating intervals of activity of duration $\epsilon$ and silence of duration $\Delta$. Duration depends on the precision of the clock synchronization. Occurrence of events of significance (e.g. sending of msg) is restricted to activity intervals (sparse events). Integer number assigned to activity interval is called timestamp. Events happening in the same activity interval happen simultaniously. System-wide consistent temporal order of all sparse events occurring in a distributed system can now be established on the basis of their global timestamps. Events occurring outside of the sphere of control of the system can happen on a dense timebase, must be transformed to sparse events by agreement protocols.

Cycle

Period of physical time between the repetitions of regular events. A cycle is specified by the duration of its period and the position of its start, the cycle start phase relative to some reference. Available precision of clock synchronization determines the shortest allowed cycle of duration in a given system.

State

The state enables the determination of a future output selely on the basis of the future input and the state the system is in. In other word, the state enables a "decoupling" of the past from the present and future. The state embodies all past history of a system. Knowing the state "supplants" knowledge of the past. For this role to be meandingful, the notion of past and future must be relevant for the system considered.

In order to facilitate the recovery of a component in case its state has been corrupted by a fault, periodic instants with a small state (ground state) have to be introduced for state recovery.

Replica Determinism

Finite-State Model with state space $Q$, input space $\Sigma$ and output space $\Delta$: This model behaves R-deterministic iff

• given a sequence of sparse real-time instants $t_{i}$
• the state of the model $q_{0}(t_{0})\in Q$
• a sequence of future inputs $a_{i}(t_{i})\in \Sigma$
• then the sequence of future outputs $b_{j}(t_{j})\in \Delta$ and the sequence of future states $q_{j}(t_{j})\in Q$ is entailed

Is regular determinism.

In addition to be replica derterministic: Replicated units (system/components) behave replica-deterministic iff they produce the same output within a bounded duration d of each other.

Component Refinements

• c-component (computational component) can be modeled by a state machine, can contain internal state.
  • Time-triggered c-components: cycle associated with each TT-c-component. computation started at start instant of cycle, finished in a priori known time interval
  • Event-triggered c-components: starts processing with new input arriving, will terminate after finishing processing.
• i-component provides connection from cluster to environment

Message Refinements

• Event triggered (ET) message
  • appended to sender queue
  • consumed by communication system when channel is free
  • appended to receiver queue
• Time triggered (TT) message
  • triggered by progression of a global notion of time
  • at start instant of cycle start of transmission is triggered
  • delivery within an a priori known interval
• Time triggered state message
  • transmitted in every cycle
  • overwrites receive buffer, no queues

Design Patterns

• Introduce a Sparse Time Base
• Introduce Few Orthogonal Concepts
• Simplify by Partitioning
• Simplify by Segmentation
• Deterministic Models
• Network of Model Hierarchies: the recursive application of the principles of abstraction and refinement leads to a hierarchy of models (aka. abstraction ladder, cf. Four Universe Model)

DSoS Conceptual Model (Chapter 3)

System

A set of components bound together in order to interact. An entity that is capable of interacting with its environment and is sensitive to the progression of time.

System of Systems (SoS)

A particular type of system, where the components are systems.

Instant/Duration

Instant is a cut of the timeline, duration is a section of the timeline.

Interface/Output Interface/Input Interface

• Interface: point of interaction between a system and its environment. Environment is everything other than the system.
• output interface: an interface of a system at which information is produced for the environment of the system. a system without an output interface is meaningless.
• input interface: an interface of a system at which information is consumed from the environment of the system.

Interfaces can be specified

• syntactically (structure of msgs)
• temporally (when is a message expected, instant, phase, frequency)
• meta-level (meaning of information crossing the interface)

Actuation (Sensing) Operation

• actuation: value change at a specific instant of time or temporally controlled sequence of value changes produced by a system at a physical output
• sensing: value change at a specific instant of time or temporally controlled sequence of value changes recorded by a system at a physical input

encompasses the exchange of information among widely different types of systems.

Message

A data structure that is formed for the purpose of communication among computer systems.

Classification of messages:

• valid: contains correct CRC
• checked: output assertion passed
• permitted: passes input assertion of the receiver
• timely: in agreement with the temporal specification
• correct: in agreement with the temporal + value specification
• insidious: permitted but incorrect

Send (Receive) Operation

sending (receiving) of a message at an interface. successful termination of a receive operation always results in the reception of a complete message.

Message Send Instant

instant, when the sending of a message starts at the sender

Message Receive Instant

instant when the receiving of a message terminates at the receiver

State Variable

relevant variable, either in the environment or in the computer system, whose value may change as time progresses

• dynamic attributes: value at a particular time instant
• static attributes: do not change, e.g. name, type, value domain, maximum rate of change

State Observation

Record of the value of a state variable, may be represented as tupel $\langle Name,Value,t_{obs}\rangle$

Image

Representation of a state variable

Value Accuracy

interpretation of the image value by the user is in agreement with the semantic content of the state variable at the instant of observation

Temporal Accuracy

temporal accurate at instant t, if duration between $t_{obs}$ and t is less than the accuracy interval $d_{acc}$, which is an application specific parameter associated with the dynamics of the given state variable.

Accuracy

value + time accuracy

(Image) Validity

valid at a given instant if it is an accurate representation of the corresponding state variable, both in value + time domain. validity is time dependent, may be invalidated by the progression of real time.

Event Observation

records the occurrence of an event. an event is a significant happening. represented by the tupel $\langle eventName,eventattributes,eventtime\rangle$

timed events are idempotent (at least once semantic), not timed events must have a exaclty once semantic

State Message

message, that contains only state observations

Periodic State Message

state message, that is sent periodically at a priori known instants. instants are common knowledge to the sender and the receivers.

Event Message

message that contains only event observations

Behaviour

temporal sequence of send operations of a system in relation to its previous receive operations, and any internal state that it retains. characterized by its send operations, though these of course can be affected by its receive operations and any internal state that it retains.

Service Specification

specification of the set of intended behaviours of a system.

Dependability

ability to deliver a service that can justifiably be trusted, where the service is the intended behaviour of the system.

Failure

event that occurs at a service interface of a given system at the instant when the actual behaviour of the system starts to deviate from the intended behaviour.

State of a System

at a given instant, the values assigned to an internal data structure of a system that records the cumulative effect of all operations (at all interfaces) and all internal events, including local clock ticks, between the startup of the system and this given instant. the system state records the effect of these operations and events on future behaviour at all interfaces.

(Abstract) State of a System

At a given instant, the (abstract) state of a system is an equivalence class of histories, where (i) a history is a complete sequence (or trace) of significant system events – input messages, output messages and internal events, including local clock ticks – between the startup instant and the given instant; and (ii) two histories are equivalent if and only if the potential behaviour of the system after one history is indistinguishable from its potential behaviour after the other. ‘Potential behaviour of the system’ means all possible future system behaviour at all interfaces, including responses to possible input operations at its interfaces. The (abstract) state of a system determines the system’s potential behaviour.

Interface State

state of a component system as viewed from a particular interface (typically subset of full state of the component)

Declared (Interface) State

values assigned to a declared data structure that can be accessed via an interface and that synthesises all relevant effects of previous receive operations

declared interface state: declared state which is part of the interface model of the considered interface.

Error/Fault

error is part of the system state, may cause a failure, fault ist the cause of an error (active when in produces an error, otherwise dormant)

Error Containment Region

well defined subsystem, contains error-detection mechanisms which detect error with high probability (error containment coverage), detains error propagation outside this subsystem.

needs at least two FCRs typically, if the FCR is fail-silent then there is no need for a special error detector (timeouts, membership lost/no message sent, ...)

Fault Containment Region

set of components considered to fail as (a) an atomic unit, (b) in a statistically independent way wrt. other fault containment regions

e.g. all components/systems that are affected by a specific offspec/damaged power supply form a FCR, all other components are in different FCRs and thus fails statistically independent for that fault.

Fault Tolerance

providing intended system behaviour in case of faults

implemented by

• error detection and subsequent recovery
• error compensation
• combinations of both

present but not detected error is called latent error

Connection

link between interfaces of interacting systems

Architectural Style

set of rules and conventions governing the connections and interactions between the components

Properties of an Interface

set of interface attributes, e.g.

• encoding of the information
• structure of the information
• meaning of the information
• temporal sequence of information exchanges
• ...

Elementary Interface

interface for elementary interactions only.

elementery interaction: all messages are transmitted according to the information push model (no control on consumer side)

Composite Interface

interface for composite interactions

composite: at least one message is tranmitted according to information pull (consumer exerts control on transmission)

Property Mismatch

disagreement among connected interfaces in one or more of their properties

Boundary Line

connection between interfaces with matching properties

Connection System

new system introduced for resolving property mismatches

Linking Interface (LIF)

interface of a component system through which it is connected to other component systems within a given SoS.

focus on interfaces that are needed to generate emergent services produced by the desired integration (e.g. replication in fault tolerant systems)

Local Interface

not a LIF

Linking Connection

connection which is introduced to resolve property mismatches, thus incorporate these systems into a system of systems with new emergent services

Interaction

sequence of msg exchange between connected interfaces

Protocol

set of rules for interactions between connected interfaces

Temporal Composability

characteristic that integration into a SoS of a component system has no influence on its temporal properties

Time Measurement by an Omniscient External Observer

one reference clock, small granularity, every event is instantly timestamped from this reference clock, temporal order of events with same timestamp cannot be reconstructed

Global Time

syncronization of local clocks to establish an approximation of a common global time. synchronized with precision $\Pi$

macrotick of global time happens after specific number of local ticks. global time is called reasonable (reasonableness condition), if granularity of the macrotick is greater than the precision $\Pi$ of the synchronization. If this is satisfied, the global timestamp of an event e (on different processors) can differ by at most 1.

Local Time

local oscillator at every node establishes a local time base for this particular node

The Time-Triggered Architecture

aus Uebersichtlichkeit nicht nochmals ausgefuehrt: Sparse Time, RT Entity, Observation (State & Event), RT Image

Model of Time

The model of time of the TTA is based on Newtonian physics. Real time progresses along a dense timeline, consisting of an infinite set of instants, from the past to the future.

Structure of the TTA

The basic building block of the TTA is a node. All nodes have access to the global time. A node consists of a communication controller (CC) and a host computer (CPU, memory, I/O, OS + SW), which are connected via the communication network interface (CNI).

In the TTA, the communication system is autonomous and executes periodically an a priori specified TDMA schedule. It reads a state message from the CNI at the sending node at the a priori known fetch instant and delivers it to the CNIs of all other nodes of the cluster at the a priori know delivery instant, replacing the previous version of the state message. The times are contained in the message descriptor list (MEDL).

Guardians

Guardians are independent units that monitor the known temporal behavior of the associated node. If a node intends to send a message outside its a priori determined time slot, the guardian will cut off the physical transmission path. Ideally, guardians must be completely independent units (own clock, power supply, clock sync algorithm).

Design Principles

Consistent Distributed Computing Base

TTA establishes a membership service to determine if any node has been affected by a failure.

Interfaces of a Node

• Real-Time Service (RS) Interface: provides the timely real-time services, therefore it has to meet the temporal specification in all specified load and fault scenarios. From a user's point of view, the internals of the node are not visible at the CNI, since they are hidden behind the RS interface.
• Diagnostic and Maintenance (DM) Interface: opens a communication channel to the internals of a node. It's used for setting/retrieving node parameters/information (e.g. fault diagnosis). The use of the DM interface requires detailed knowledge about th internal object and behavior of the node and is usually not time-critical.
• Configuration Planning (CP) Interface: it's used during the integration phase to generate the "glue" between the nearly autonomous nodes. The use of the CP interface doesn't require detailed knowledge about the internals of a node and is not time-critical.
• Temporal Firewall: an interface that prevents propagation of control errors by design.

Composability

For an architecture to be composable in the temporal domain, it must adhere to the following four principles with respect to the RS interface:

• Independent development of nodes: The architecture has to support the precise specification (value- & temporal domain) of all node services at the level of architecture design.
• Stability of prior services: This ensures that the validated service of a node -- both in the value domain and in the time domain -- isn't refuted by the integration of the node into a system.
• Constructive integration: This principle requires that if $n$ nodes are already integrated, the integration of the $n+1$'th node must not disturb the correct operation of the $n$ already integrated nodes.
• Replica determinism: A set of replicated nodes is replica determinate if all the members of this set have the same externally visible state, and produce the same output messages at points in time that are at most an interval of $d$ time units apart.

Further Principles

• Scalability: Horizontal layering (abstraction) and vertical layering (partitioning)
• Transparent Implementation of Fault Tolerance: Introducing a dedicated fault tolerance layer in a Node (cf. Figure 11, Page 8)
  • before (from top to bottom): Application Host <> Basic CNI <> CC
  • afterwards: Application Host <> FTU CNI <> Fault Tolerance Layer <> Basic CNI <> CC
• Openness: e.g. that the DM- and CP-interface are accessible via CORBA

Communication

TTP/C Protocol

The TTP/C protocol is a fault-tolerant time-triggered protocol that provides the following services:

• Autonomous fault-tolerant message transport with known delay and bounded jitter between the CNIs by employing a TDMA medium access strategy on replicated communication channels
• Fault-tolerant clock synchronization that establishes the global time base without relying on a central time server
• Membership service to inform every node consistently about the "health-state" of every other node of the cluster
• Clique avoidance to detect and eliminate the formation of cliques in case the fault hypothesis is violated

Every node measures the difference between the a priori known expected and the actually observed arrival time of a correct message to learn about the difference between the sender's clock and the receiver's clock. This information is used by a fault-tolerant average algorithm to calculate periodically a correction term for the local clock in order to keep the clock synchrony with all other clocks of the cluster.

TTP/A Protocol

It's used to connect low-cost smart transducers to a node of the TTA, which acts as the master of a transducer cluster. In TTP/A the CNI memory element has been expanded at the transducer side to hald a simple interface file system (IFS, it holds RT data, calibration data, diagnostic data, ...). There're two types of rounds:

• master-slave (MS) rounds: read/write records from the IFS in order to implement the DM- and CP interface
• multi-partner (MP) rounds are periodic and transport data from selected IFS records of severl transducers accross the TTP/A cluster to implement the RS service

Event Message Channels

In the TTA, event message channels are constructed on top of the basic time-triggered communication service by assigning an a priori specified number of bytes of selected time-triggered messages to the event-triggered message transport service. In order to implement the event semantics at the sender and receiver, two message queues must be provided in the CNIs: the sender queue at the sender's CNI and the receiver queue at the receiver's CNI.

Fault Tolerance

Fault Hypothesis

Any fault-tolerant design activity starts with the specification of the fault hypothesis. The fault hypothesis states the types and number of faults that the system should tolerate.

Fault Tolerant Unit (FTU)

A set of nodes or software subsystems that compute the same function in order to tolerate the failure of any of its independent constituent parts without a degradation of service. The classic form of a FTU is TMR.

Never-Give-Up (NGU) Strategy

If the environment violates the fault hypothesis -- in a properly designed application this must be a rare event -- then the TTA activates a NGU strategy. The NGU strategy is highly application specific.

Compositional design of RT systems: A conceptual basis for specification of linking interfaces

Sparse time base

Continuum of real-time is partitioned into a sequence of alternating intervals of activity of duration ε and silence of duration Δ. Duration depends on the precision of the clock synchronization. Occurrence of events of significance (e.g. sending of msg) is restricted to activity intervals (sparse events). Integer number assigned to activity interval is called timestamp. Events happening in the same activity interval happen simultaniously. System-wide consistent temporal order of all sqarse events occurring in a distributed system can now be established on the basis of their global timestamps. Events occurring outside of the sphere of control of the system can happen on a dense timebase, must be transformed to sparse events by agreement protocols.

Component

• self-contained subsystem
• can be used as building block
• provides desired service to environment via well specified interfaces
• encapsulation when used in larger context

Interface, Charterization of a LIF

common boundary between components, LIF is characterized by

• data properties (structure and semantics of data items)
• temporal properties (temporal conditions that have to be sat for control- and data delivery validity)

rules for message check at interface:

• valid: contains correct CRC
• checked: output assertion passed
• permitted: passes input assertion of the receiver
• timely: in agreement with the temporal specification
• correct: in agreement with the temporal + value specification
• insidious: permitted but incorrect

Categories of interfaces

Service Providing Linking Interface (SPLIF)

offers service to component-environment, primary interface of a component

Service Requesting Linking Interface (SRLIF)

requesting service from other component/enviroment.

A user of a SPLIF might not be aware of the SRLIF of the component.

Configuration Planning (CP) Interface

global resource manager for configuration of initial and subsequent components for providing services, sporadic access

Diagnostic and Management (DM) Interface

selective access to operational internals for monitoring and diagnostic purposes, can be used for parameterization

Closed Component

environment interaction only via single SPLIF, produced output messages are function of SPLIF input messages and SPLIF state. deterministic closed component if deterministic function in value and time domain. Example .. a stack function

Semi-closed component has in addition to LIF input messages only one other type of input, namely a clock message from a synchronous clock denoting the instant of the beginning of a sparse time granule. Example .. a clock that produce an output every n-th tick. Semi closed component is time aware, closed component not

Open Component

has at least one SRLIF that accept inputs from natural environment (reality as it exists in nature, not digital model of reality). e.g. interrupt driven component with interrupts from natural environment.

Semi-open component: can exchange data with environment without delegating control to the environment (e.g. sampling system)

RT Entity

state variable which changes value when time progresses

• static attributes: do not change during lifetime (e.g. name, type, value domain, max rate of change)
• dynamic attributes: change with time (value set at particular instant of time)

information about the state of rt entity is $observation=\langle Name,Value,t_{obs}\rangle$

continues RT entity can be observed at any instant, discrete RT entity only when state not changes

RT Image

temporally accurate picture of RT entity at instant t, if duration between $t_{obs}$ and t is smaller than $d_{acc}$, the accuracy interval, an application specific parameter associated with the dynamics of the given RT entity.

RT image is valid at a given instant if it is an accurate representation of a RT entity in value and time domain

State information vs. Event information

state observation records the state of a state variable at a particular instant.

event information describes an event, which is the change of a state of a RT entity an an instant, contains the difference between old state value and new state value, can be expressed by $\langle Name,Valuedifference,Timeofevent\rangle$ event information require exactly once semantics, must be queued on sending and consumed on receiving side

periodic state observation vs. sporadic event observation are alternative approaches. if no minimum duration between events exists, the receiver must be infinitly fast

Composition

a composition is the act of combining parts or elements to form a whole. composability is the ease of forming a whole by combining parts.

Principles for an architecture to support composability with respect to LIF and RT

Independence

• clearly distinguish between architecture- and component design
• interface data structure must be prcisely specified in value and time domain
• proper LIF service model of the component service must be available
• component designer must know what to expect when from the environment

Invariance

ensuring invariance of existing properties of components, so validated service of a component is not refuted by integration into an encompassing SoS

Growth

• concerned with performance of communication system
• n components already integrated, n -> n+1 will not disturb correct operation of n already integrated components (network resources, no degradation at critical instant)

Resilience

for fault tolerance, architecture and components should support replica determinism (members of of the rep-det set of components have same encapsulated state and produce same output in time interval of at most d, as seen from omniscient observer, d dertermined by the time it takes to replace a faulty message by a correct one)

LIF specification

mediator between service supplier and service user.

• precise in value and time domain
• complete in sense that it contains all information required to understand and use the services of the component
• minimal in sense that it contains only information that is essentially required by the user

Syntactic specification

specification of data elements crossing the interface, sequence of bits in a msg, larger chunks (number, string, image, ...), descriptive name to establish a link between chunk and its meaning helps human understanding.

Temporal specification

send and receive instants, order of messages, rate of msg arrival

in non safety-critical applications temporal spec can be expressed in probabilistic terms

Operational input assertion

specifies an executable predicate on incoming msg and interface state to determine whether the msg is permitted at a given instant

LIF service model specification

specify conceptual interface model relating chunk names (syntactic spec) to the users conceptual world and thus assign deeper meaning. bridges gap between information model and user model.

Characteristics of a state message

• Content: state message contains state information
• Flow Control: sent and received periodically at a priori known time instants, implicit unidirectional flow control
• Delivery Method: at least once
• Error Detection: at receiver, based on a priori knowledge of receiving instant

Communication Network Interface (CNI) memory at sender forms output firewall, and at receiver forms input firewall. sender pushes information into its temporal firewall, receiver pulls input out of firewall. transport is realized by TT-protocol. on input, precise operational interface spec is pre-condition for correct operation, on output precise interface spec is post-condition. components interacting via temporal firewalls are semi-open.

Characteristics of an event message

• Content: e-msg contains event information
• Flow Control: sent as a consequence of the occurrence of a significant event, receiver has no a-priori knowledge at what instant an event msg will arrive. explicit flow control, bi-directional protocol
• Delivery Method: exactly once semantics
• Error Detection: sender based on timeout from receiver ack

needed for communication of sporadic processes with a priori unknown sporadic pattern

number of problems in realtime systems

• component is open component (interacts with environment via event msgs)
• temporal control is delegated to environment, not in sphere of control of component
• control error propagation into component is possible (in contrast to semi-open)
• bi-directional protocol for error detection
  • server overload
  • communication system overload

LIF service model

interprets the information chunks formed by the syntactic specification.

• for closed component: can be formalized, relationship between I/O depends on discrete algorithms implemented within the component, no input from natural environment
• for open component: inputs from natural environment, concepts in description must fit well with concepts in users internal conceptual world (description must be understood)
  • user orientation: concepts must be familiar to user (user with engineering background engineering terms should be used)
  • goal orientation: relationship between user intent and the services provided at LIF must be exposed in the LIF service model
  • system view: user needs to consider system-wide effects of component interaction; LIF service spec must address all direct and indirect effects across LIF

Two types of LIF

Stateless LIF

responce to service request depends on the parameters of the request only and is independent of request time

Stateful LIF

response depends on request time too (different results depending on history of the component or the state of the environment)

A methodology for safety case development

Safety case

A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment.

for implementation we need to

• make an explicit set of claims about the system
• produce the supporting evidence
• make clear the assumptions and judgements underlying the arguments
• provide a set of safety arguments that link the claims to the evidence
• allow different viewpoints and levels of detail

Elements of a safety case

Claim

about a property of the system or some subsystem

Evidence

basis of the safety argument: facts (scientific principles), assumptions, subclaims derived from a lower-level sub-argument

Argument

linking evidence to claim, deterministic, probabilistic or qualitative

Inference

transformational rules for the argument

Types of claims

safety case is broken down into claims about different attributes for various subsystems

• reliability and availability
• usability (by the operator)
• security, fail-safety
• functional correctness
• accuracy
• time response, robustness to overload
• maintainability, modifiability, ...

Types of argument

• Deterministic: application of predetermined rules to derive a true/false claim (formal proof of compliance to a spec, demonstration of a safety requirement, ...)
• Probabilistic: quantitative statistical reasoning (MTTF, MTTR, reliability testing)
• Qualitative: compliance with rules that have an indirect link to the desired attributes (compliance with QMS standards, staff skills and experience)

choise of argument will depend on available evidence and type of claim (claims for reliability will be supported by statistical arguments, maintainabilite is mor qualitiative, ...)

Source of evidence

arguments themselves can utilize evidence from

• the design
• development process
• simulated experience (reliability testing)
• prior field experience

implementing the safety case

• safety case should be considered throughout the project
  • integration of the safety case into the design and devolopment process
  • layered safety cases (top level sc with subsidiary sc for subsystems)
  • traceability between system and subsystem levels: initially requirements might be attributes such as security or maintainability. but a more detailed level of implementation will convert requirements into design requirements that are implemented in subsystems. so it is important to have a traceability between these levels for a clear link between design features and safety attributes.
  • design for assesment: integrates the production of the safety case with the design of the system. identification of candidate design options to construct preliminary safety case (identification of hazardous system state + appropriate counter measures. safety cases are assessed to establish whether:
    • design implements safety functions and attributes
    • design criteria ar satisfied
    • design is feasible
    • associated safety arguments are credible
    • approach is cost-effective

safety case life-cycle

safety case life-cycle should be integral part of the overall system development, during whole lifetime of system.

main stages of safety-case evolution:

• safety functions and top-level safety attributes identification
• system architecture and outline safete case identification
• preliminary assesment of design options:
  • costs and risks (implementation and safety case)
  • long-term support
• progressive elaboration of the design and safety case in parallel
  • safety case requirements part of subsystem spec
  • reviews of subsystem safety cases
• integration into final sc
• long-term support infrastructure plans
• approval
• long-term monitoring and audits
  • areas of concern
  • support processes
  • gathering field evidence to support assumptions
• system updates and corrections

safety case contents

• environment descriptions
• PES (Programmable Electronic Safety-related Systems) safety requirements (safety functions, reliability and other safety attributes, anticipated changes)
• PES system architecture (subsystems, interconnections, ...)
• planned implementation approach (at least one safety argument for each requirement, identification of all design assumptions used in the safety argument (claim limits, failure modes, ...), identify supporting evidence)
• subsystem design and safety arguments
• long term support requirements
• PES maintenance and operation procedures (safety case support infrastructure)
• evidence of quality and safety management (results of QA audits, safety audits, evidence that identified problems are resolved)
• references

Computing for Embedded Systems

Model of computation

A model of computation governs the interaction of components in a design.

Examples for defining components

• procedure
• function
• process
• thread

Name the two types of patterns

• architectural
• design

What is a framework

A framework is a set of constraints on components and their interaction, and a set of benefits that derive from those constraints. Examples: operating systems, programming languages usw.

Attributes of a framework

• Ontology. A framework defines what it means to be a component. What is a component (subroutine, state transformation, process, ...)
• Epistemology. A framework defines states of knowledge. What does the framework know about the components, what do components know of each other
• Protocols. A framework constrains the mechanisms by which components can interact.
• Lexicon. The lexicon of a framework is the vocabulary of the interaction of components.

Architecture Description Language

define a model of computation

EXAMPLES OF MODELS OF COMPUTATION

• Continuous time and differential equations
• Discrete time and difference equations
• State machines
• Synchronous/reactive models
• Discrete-event models
• Cycle-driven models
• Rate monotonic scheduling
• Synchronous message passing
• Asynchronous message passing
• Timed CSP and timed PN
• Publish and subscribe
• Unstructured events

the ways to mix frameworks

• specialization:

one framework is simply a more restricted version of another

• hierarchically:

A component in one framework is actually an aggregate of components in another

Matlab / Simulink

Was ist Matlab? Was ist Simulink?

MATLAB (matrix laboratory) is a numerical computing environment and fourth-generation programming language. It allows matrix manipulations, plotting of functions and data, implementation of algorithms, creation of user interfaces, and interfacing with programs written in other languages, including C, C++, Java, and Fortran. Source: [1]

Simulink is an extension to MATLAB that allows engineers to rapidly and accurately build computer models of dynamical systems using block diagram notation. Using Simulink, it is easy to model complex nonlinear systems. A Simulink model can include continuous and discrete-time components. Additionally, a Simulink model can produce graphical animations that show the progress of a simulation visually, significantly enhancing understanding of the system's behavior. (Source: Mastering Simulink)

Was ist ein Blockdiagramm?

Block diagram notation is a graphical means with which to represent dynamical systems. A block diagram describes a set of relationships that hold simultaneously. All blocks in a block diagram may be active at once, so a block diagram may be thought if as representing a set of simultaneous equations. (Source: Mastering Simulink)

Wozu wird dieses benötigt?

They were originally used to represent linear time-invariant continuous systems, but where later extended to represent complex nonlinear systems containing continuous-time and discrete-time components. (Source: Mastering Simulink)

Was sind Sink- und Source-Blöcke?

Source Block: The inputs to a model in simulink are called sources, located in the source block library. A source block has no inputs and at least one output.

Sink Block: The output of the simulink system is received by sink blocks. They provide means to view and store data. Examples are the scope or the XY-graph. (Source: Mastering Simulink)

Wie erfolgt "Model Building" in Matlab/Simulink?

Graphically with block diagrams provided by simulink. (TODO: wem fällt was besseres ein?)

Was ist der Unterschied bei der Modellierung von kontinuierlichen und diskreten Systemen in M/S?

Continuous systems are modeled by using differential equations, where discrete systems are modeled by difference equations.(Source: Mastering Simulink)

Wie können in Matlab/Simulink hierarchische Modelle mit Subsystemen erstellt werden?

There are two ways to implement a subsystem in simulink. Either by encapsulating a portion of an existing model in a subsystem using EDIT:Create Subsystem or we can use a Subsystem block from the Ports & Subsystems block library. (Source: Mastering Simulink) TODO: Wenn hier jemand eine bessere Antwort auf die Frage finden würde wäre ich sehr dankbar.

Weitere Antwort: Subsystems and masked blocks, the later has the ability to use a custom symbol and parameter dialog boxes and allows to create custom blocks that can be used as if it were a standard simple block.

Two Ways to Create a Subsystem

1- Create a Subsystem by Adding the Subsystem Block Add a Subsystem block to your model, then open that block and add the blocks that it contains to the subsystem window.

2- Create a Subsystem by Grouping Existing Blocks Add the blocks that make up the subsystem, then group those blocks into a subsystem. [source [2]]

Was ist eine s-function und wozu wird sie benötigt? Wie kompiliert man s-functions? Erlären Sie C language s-functions allgemein und anhand eines praktischen Beispiels! (Kapitel 10.5)

S-Functions allow you to define custom Simulink blocks using MATLAB, C, C++, Ada or FORTRAN language code. They can, for example, be used in situations where it's easier to describe a subsystem algorithmically than in block diagram notation. They also might improve the efficiency of a simulation, particularly in a model involving algebraic loops. (Source: Mastering Simulink)

How to compile S-Functions? For C functions type "mex source.c" in matlab command line

C language S-Functions provide all the capabilities available via M-File S-Functions, such as dynamic sizing and multiple sample times. C language S-Functions can also be written to provide capabilities not directly available within M-File S-Functions. In particular, C language S-Functions blocks can have multiple input ports and multiple output ports. In contrast to M-file S-Functions, the flag mechanism is not used, but a single C source file is provided that contains a set of functions with specified names. (Source: Mastering Simulink)

Erlären Sie Stateflow allgemein und anhand eines praktischen Beispiels!

Stateflow is an extension to Simulink that provides a powerful environment with which to add finite state machines to Simulink models. Stateflow is built around the Statechart formalism. While it is possible to model finite state machine logic using standard Simulink blocks, Stateflow adds the ability to model finite state subsystems using a notation that is specifically designed for this purpose. (Source: Mastering Simulink)

Wozu wird Simulink-Coder (earlier Real-Time Workshop) benötigt? Erläutern Sie die Vorteile der Verwendung des Simulink-Coders!

Simulink-Coder is an extension to Simulink that translates Simulink models into executable code. It can be configured to produce executable code for the computer on which Simulink is running, another PC, a digital signal processing card, or even an embedded controller. It can be used to produce a model that executes much faster than the original Simulink model, facilitating optimization and Monte Carlo analysis. (Source: Mastering Simulink)