Architecture Modeling - SPES 2020

More documents

Recommendations

Info

Architecture Modeling and so forth. Each of such design steps usually involves an assignment of requirements to the identified components. Some requirements are usually derived from formerly identified requirements, while other requirement occur due to the introduction of new components and interfaces. To stress the air conditioning example, we may have the requirement for an air-conditioning function (in the functional perspective) to provide air from the environment of an airplane with certain quantity and temperature. To show the simplest form of deriving a requirement for the logical perspective at the same abstraction level, there may be exactly one logical component performing the air conditioning function. In such a case, it seems to be obvious to assign the same requirement to the logical component as to the corresponding function. In more complex settings, logical components may perform several functions (sequentially, parallel, or in any other order), or several logical components may be involved performing a single functionality. Here, deriving requirements for one perspective from another may be more complex, particularly for the latter case. 3 The same can be said for the relation between logical and technical components. A logical component may be performed by a single technical entity. It may be also performed by a composition of different entities, may be involving mechanical, computational and other components. Indeed there may be requirements that are unique to specific perspectives. For example, geometrical constraints such as packaging sizes, cable lengths, and so on become important only in the geometrical perspective. On the other hand, there are typically requirements that are important for multiple perspectives. Requirements identified for system functions for example are important in order to establish justification for proper system design. Satisfaction of those requirements can however often not be established in the functional perspective, e.g. due to missing specification of internal behavior. SPESMM provides concepts to reason about requirements across different perspectives, and to establish the corresponding relations. Abstraction Levels The same problems that occur with respect to reasoning about contracts across different perspectives hold for abstraction levels. When a system is designed incrementally, the same system is represented at different levels of granularity. Although various refinement steps can be established by decomposition of components, there are other cases where changing the abstraction level is more appropriate. This may be simply due to organizational boundaries, where different departments in a company are responsible for certain subsystems. A more formal reason is the fact, that refinement not always follows a decomposition approach, but demands for more complex m-to-n relations. Note that there is no explicit deployment defined for different aspects of components. The reason for this is, that the specification of different aspects has no direction. Instead, aspect specifications of a component are often closely and interdependently entangled, and relations between different aspects of specifications have to be made explicit. An example for multiaspect specification can be found for example in [18]. 4.4.1 Mapping Since the requirements for creating interfaces between perspectives and between abstraction levels are very similar, the SPESMM introduces the common concept of mapping. Technically, 3 A convenient way to circumvent such problems is to start with a surrounding component that uses decomposition to achieve the intended result, and that keeps the simple one-to-one relation between functions and logical components 62/ 156
Architecture Modeling a mapping is similar to a component. It has interfaces consisting of ports, and it has internal behavior defined in terms of an HRC state machine. Its interfaces are however not used for interaction with other components but to relate different models. As Figure 4.10 shows, a mapping connects (arbitrary) ports of two different models of a design. Mappings are asymmetric in that the roles of connected model artifacts are different. A mapping can be considered as an observer of one of the participating models. In Figure 4.10 for example, the depicted mapping “observes” the behavior of component S of the right hand model. Due to its internal behavior, a mapping provides a well defined (possibly modified) view to the behavior of the “observed” model. More important, the observer approach gives means to the fact, that models of a design are closely related to each other. Model artifacts within a perspective at a certain abstraction level are allocated to artifacts of other perspectives, and artifacts at a lower level are considered to realize those of a higher abstraction level. In this sense, a mapping provides the foundation to reason about satisfaction of an observing model by another (observed) model. Logical Perspective temp occurs each 50ms temp Delay between temp and control within [20ms,25ms] AirTempSystem control Mapping Technical Perspective tempVal temp temp Data control Var1 ECU Capture Task Figure 4.10: Mapping Example Scheduler airTemp CtrlTask Technically, a mapping can be used to “replace” components within the observing model, as depicted in Figure 4.11. While replacing, the mapping gets associated with the set of contracts that have been associated to the replaced components. This gives means to the proof obligation corresponding to the question whether the observed model satisfies the contracts defined for the observing model. In fact, the situation is very similar to those of virtual integration testing. If the resulting system, containing the mapping and the observed model, is considered as a single component as shown in Figure 4.11, the same proof obligations apply as for VIT. However, refinement has to be shown not for the composition of all contracts in the observed model, but only for the composition of those contracts that are associated to components having links to the mapping. The result is that, whenever the contracts of the components of the observed model are satisfied, then the contracts of the observing models are also satisfied with respect to the internal behavior of the mapping. Mappings thus provide well-defined interfaces between artifacts of models within different perspectives and abstraction levels. However, the corresponding proof obligations are valid only with respect to the behavior of the mapping. Mapping can for example be used to perform interface refinement. The upper part of Figure 4.12 shows a component with an outport providing some integer valued data. At the next lower abstraction level, the same component has a refined port providing 3-Bit digital data. The mapping shown in the figure “converts” the 3-Bit values of the refined component into (more abstract) integer values. In this example, the internal be- Var2 tempSel 63/ 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 and 54: Architecture Modeling When specifyi
Page 55 and 56: Architecture Modeling next selectio
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: Architecture Modeling 4.3.2 Establi
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 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

Create successful ePaper yourself

Delete template?

Save as template?