Architecture Modeling - SPES 2020

More documents

Recommendations

Info

Architecture Modeling Consistency Consistency captures the fact that a set of contracts is not contradictory. An inconsistent set of contracts is not usable at all, because it does not allow for any useful implementation. The most easy way to get an inconsistent set of contracts is to define an ”empty” guarantee for any possible context. For example, we could state the following guarantees: (i) whenever the component receives an event from its environment, the next event on its output will be a, and (ii) whenever the component receives an event from its environment, the next event on its output will be b. If we do not further restrict the behavior of the environment (for example by saying that this happens under no conditions), the result will be inconsistent. A detailed discussion about receptiveness and consistency together with formal definitions can be found in Section 6.2.1. 4.1.1 Functional Specifications A simple example for contract-based specification of functional requirements is depicted in Figure 4.1. It shows a possible design of an air conditioning system at the logical perspective. The interface of the (logical) component has been identified during former design steps. Not all relevant ports have been shown, but we see a port providing status information about the current air temperature (airTemp), an input port allowing to select the temperature (tempSelect), and ports representing the current air flow (airIn, airOut). The figure shows also some requirements associated to the component, stated in terms of contracts. The specification is largely simplified and even does not follow correct RSL syntax. The green part is the (strong) assumption of the component. The figure reflects the fact, that all contracts of a component share the same strong assumptions. Blue parts are the guarantees. Weak assumptions are yellow. In our case, they are always true and thus do not further restrict the environment. -20°C
Architecture Modeling next selection. The second assertion defines what happens before this minute. Obviously, it should not be allowed that the temperature provided after a new selection becomes too high or too low (maybe due to inappropriate heating or cooling). The specification of the second guarantee thus states, that temperature fluctuation is within an appropriate range, i.e., the first momentum of some hull curve of the difference is less than 0. 4.1.2 Real–Time The very same system could be instantiated at lower abstraction level as depicted in Figure 4.2. It shows a chain of components involved to perform the air conditioning function. A tempSens component represents the sensor acquiring the temperature of the fuselage. The sensor values are captured, stored for later use (such as visualization), and forwarded to the temperature control component AirTempControl. The control component calculates control parameters with respect to the incoming temperature and the selected one (not shown), thus implementing a classical control loop. The AirCondition component models a physical part, possibly consisting of heating and cooling elements, compressors, etc. temp occurs each 50ms with jitter 5ms tempSensor Delay between temp and tempData within [5ms,7ms] tempData occurs each 50ms with jitter 10ms temp tempData Capture Delay between tempData and control within [10ms,12ms] control AirTempControl AirCondition Figure 4.2: Real-Time Contracts Example Derived from the demands of such control loop (e.g. with respect to stability), it might be required that the loop is executed periodically with a certain period and maximum jitter. Due to other demands, maximum delays might needed to be satisfied by the control loop. These requirements belong to the classical real-time domain, and can be represented by a set of realtime contracts as depicted in the figure. The contract associated to the component Capture specifies the strong assumption that the component gets an input each 50ms with a maximum jitter of 5ms. Under this condition, the component is required to deliver the sensor value within a time span of 5 to 7ms. A similar contract is assigned to the control component, stating that the maximum jitter is 10ms, and the requirement to deliver control parameters between 10ms and 12ms after it has received an input. 4.1.3 Safety Looking at components under the safety aspect requires to address the dysfunctional behavior of them. When designing a redundant architecture, for instance, the specification needs to express that a functional failure can only occur when failures in (all) redundant sub-functions can occur. A typical contract thus looks like as depicted in Figure 4.3. The contract has the 51/ 156
Page 1 and 2:
Architecture Modeling ∗ Andreas B
Page 3 and 4: Contents 1 Introduction 1 2 Quick-T
Page 5 and 6: 1 Introduction This document propos
Page 7 and 8: Architecture Modeling allowing to m
Page 9 and 10: Architecture Modeling creating a vi
Page 11 and 12: Architecture Modeling the design it
Page 13 and 14: Architecture Modeling of the logica
Page 15 and 16: Architecture Modeling realization o
Page 17 and 18: Architecture Modeling can usually o
Page 19 and 20: 3 The Architecture Meta-Model In Se
Page 21 and 22: Abstraction-Levels (detail increase
Page 23 and 24: 3.2.2 Functional Perspective Archit
Page 25 and 26: Architecture Modeling The semantics
Page 27 and 28: Architecture Modeling expressed by
Page 29 and 30: Architecture Modeling computing cap
Page 31 and 32: 3.2.5 Geometrical Perspective Archi
Page 33 and 34: ShapeCompositionOperator intersecti
Page 35 and 36: Architecture Modeling The constrain
Page 37 and 38: Architecture Modeling of particular
Page 39 and 40: Architecture Modeling Shape that de
Page 41 and 42: Architecture Modeling Conjugation o
Page 43 and 44: RichComponent Architecture Modeling
Page 45 and 46: MultiplicityElement +part 0..* Rich
Page 47 and 48: ComponentC Architecture Modeling pa
Page 49 and 50: 4 Steps in Component-Based Design T
Page 51 and 52: Architecture Modeling Assume/guaran
Page 53: Architecture Modeling When specifyi
Page 57 and 58: Architecture Modeling ports must ha
Page 59 and 60: established if (and only if): Archi
Page 61 and 62: 12°C < tempSelect < 35°C actTemp
Page 63 and 64: Architecture Modeling The component
Page 65 and 66: Architecture Modeling 4.3.2 Establi
Page 67 and 68: Architecture Modeling a mapping is
Page 69 and 70: Architecture Modeling Another impor
Page 71 and 72: 5 Using the Architecture Meta-Model
Page 73 and 74: Architecture Modeling Design proces
Page 75 and 76: Architecture Modeling abstraction l
Page 77 and 78: Pwr1 Pedal_Pos1 Pwr2 Pedal_Pos2 CMD
Page 79 and 80: Architecture Modeling Figure 5.4: O
Page 81 and 82: Architecture Modeling Figure 5.7: L
Page 83 and 84: Architecture Modeling Figure 5.9: T
Page 85 and 86: Architecture Modeling Figure 5.12:
Page 89 and 90: Architecture Modeling However this
Page 91 and 92: Architecture Modeling The considera
Page 97 and 98: Architecture Modeling tasks Command
Page 99 and 100: Architecture Modeling of the V, suc
Page 101 and 102: Architecture Modeling thus decorate
Page 103 and 104: Architecture Modeling In summary, P
Page 105 and 106:
Architecture Modeling OEMs are incr
Page 107 and 108:
Architecture Modeling provide effec
Page 109 and 110:
Architecture Modeling Figure 5.24:
Page 111 and 112:
Architecture Modeling patterns, cap
Page 113 and 114:
Architecture Modeling 6.1 Syntax an
Page 115 and 116:
6.1.1.1.1 Attribuute Definit tion a
Page 117 and 118:
Constrrain Eventts with Co ondition
Page 119 and 120:
These events used in the “and the
Page 121 and 122:
Formalization: whenever StartButton
Page 123 and 124:
Architecture Modeling Basic bloock
Page 125 and 126:
6.1.1.1.1.3 Conditions Conditions c
Page 127 and 128:
6.1.1.1.2.2 Seammless Con ncatenati
Page 129 and 130:
e3 && (clk==0) e1 idle pre e1 idle
Page 131 and 132:
Pattern whenever event occurs condi
Page 133 and 134:
If the brake force is above 80% for
Page 135 and 136:
Pattern S3: Failure shall not be ca
Page 137 and 138:
Pattern S9: failureCondition failur
Page 139 and 140:
Pattern R2: Event occurs each perio
Page 141 and 142:
idle e1 |clk:=0 e2 && (l
Page 143 and 144:
The function : allocates a singl
Page 145 and 146:
Examplees of clocks: • Run: {c=0@
Page 147 and 148:
Architecture Modeling 1. For σ ∈
Page 149 and 150:
Architecture Modeling Traces accord
Page 151 and 152:
Architecture Modeling Definition 6.
Page 153 and 154:
Architecture Modeling the one given
Page 155 and 156:
Architecture Modeling Decomposition
Page 157 and 158:
Bibliography [1] ARINC 653 - Avioni
Page 159 and 160:
Architecture Modeling [26] Holger G
show all

Architecture Modeling - SPES 2020

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?