Architecture Modeling - SPES 2020

More documents

Recommendations

Info

:ForwardSensor :ForwardSensor objects Architecture Modeling objects Acc RefinedAcc :FollowCtrl speed accel :Ctrl speed accel «Realize» :SpeedCtrl speed accel accStatus :Arbitration accel Figure 2.4: Refinement of a logical architecture of an ACC These views correspond to a perspective(↑), which thereby is considered a viewpoint(↑). As viewpoints are orthogonal to abstraction levels, the same holds for perspectives. The concept of perspectives allows to group views of different disciplines in order to cope with complexity. Currently we distinguish five perspectives. Operational perspective In the operation perspective(↑) the context of the system is considered. That means the embedding of the system under development in its environment is modeled and analysed including the interactions of the system with its environment. As a result the system boundary is determined, i. e. its interface, as well as requirements on the interface behavior. Functional perspective In the functional perspective(↑) the functional needs of the system and their breakdown into sub-functions is modeled that together realize the top-level system functions. Logical perspective In the logical perspective(↑) the system under development is decomposed by means of hierarchical components(↑) that implement the functions identified in the functional perspective. Thus, the logical perspective serves as a partitioning of functions driven by concerns(↑) like performance, reusability and management of the supply chain, i. e. to consider the interfaces between organizations in the supply chain. However, any kind of resources or properties of a target platform are still neglected here. Technical perspective In the technical perspective(↑) the electrical and electronical architecture, the software and mechanical parts of the system under development are described. That encompasses mechanical, hydraulic parts, and electronic control units, buses, and software tasks, where the components of a view corresponding to the logical perspective shall be allocated to. While in the logical perspective it is usually assumed that each component can always be executed, in the technical perspective resource limitations come into play. Some resources, e. g. electronic control units, will be shared by multiple components, whose behaviour will therefore depend on the properties of the resource as well as other components allocated to the very same resource. The allocation of components 8/ 156
Architecture Modeling of the logical perspective to elements of the technical perspective results in a hardwaresoftware partitioning. Geometrical perspective In the geometrical perspective(↑) the physical layout of the system is considered. While in the technical perspective some resource is modelled in terms of its properties, its interfaces and its behaviour, in the geometrical perspective its spatial dimensions are modelled. The geometrical perspective deals for example with cable lengths and space limitations. The concept of different perspectives and abstraction levels is inspired by partitions of EAST- ADL abstraction levels [6] and meetings with industrial partners of the SPES2020 project. Taking a look at EAST-ADL one can see that one distinct EAST-ADL architecture level is split into different perspective models: The Design Level contains a Functional Design Architecture as well as a Hardware Design Architecture. We generalized that concept by means of the perspectives allowing the partitioning of architectures in each level of abstraction. The entities and their interfaces defined in different perspectives do not need to be compatible to each other. For example, three interacting functions defined at the functional perspective may be modelled as two components in a logical perspective. The palette of actually used perspectives can be different at each abstraction level. In early design stages for example, when the functions of the system are to be defined, the target platform (modelled in the technical perspective later on) need not necessarily be of interest. 2.3 Heterogeneous Rich Components The meta-model of Heterogeneous Rich Components (HRC), which originates from the European SPEEDS project [42], constitutes the core of the architecture meta-model proposed in SPES. This section gives a short introduction into its concepts. 2.3.1 Component Model The paradigm of component-based design is well established and used in many different application domains. In standards like EAST-ADL [6] and AUTOSAR [9], a component is the basic design-entity structuring any model. A component(↑) has a well defined interfaces and is the Component Port C1 aspect specification aspect realization conforms to Figure 2.5: Components, aspect specification and realization basic entity of any model. The interfaces allow to abstract from the internals of a component and to reuse it in different design contexts. The notion of components can be established independently of any design domain. That is, a component can model a reusable piece of software, 9/ 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: Architecture Modeling the design it
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 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 87 and 88:
Page 89 and 90:
Architecture Modeling However this
Page 91 and 92:
Architecture Modeling The considera
Page 93 and 94:
Page 95 and 96:
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:
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?