Architecture Modeling - SPES 2020

More documents

Recommendations

Info

LSI 1 Architecture Modeling • The hardware perspective in which the connections between the sensors and the computers have to be found • The geometrical perspective which gives the possibility to evaluate the result of connections by allowing to express distances and length for the cables Accel. Left Sensor Left Side Impact Logical Perspective Technical Perspective Geometrical Perspective Pressure Left Sensor Redundant Airbag System Right Side Impact Front Impact LSI 2 RSI 1 RSI 2 FI 1 FI 2 … … Decomposition … Pressure Front Sensor Pressure Front Sensor Independence constraint Port ECU1 Accel. Sensor Front Type ECU Type ASF1 ASF2 ASF3 ASF4 Acceleration Sensor Type ECU2 ECU3 ECU4 Accel. Sensor Left Type Sensor Type Inheritance Accel. Sensor Right … Pressure Sensor Type … Acceleration Sensor Pressure Sensor Figure 3.21: Airbagsystem on the different perspectives (x,y,z) (x,y,z) (x,y,z) (x,y,z) ECU Connection/Cable Figure 3.21 shows a schematic of the example system on these perspectives. All relations between the elements are only partially displayed. Logical Perspective The logical perspective contains the “Redundant Airbag System” as its root node, which is decomposed into the three individual systems for crash detection. Each of them shall detect a specific crash scenario. A frontal impact is recognized by the “Front Impact System” (FI) and left or right side impacts by the “Left Side Impact” (LSI) and the “Right Side Impact” (RSI) systems. Therefore each of the systems is connected to a set of pressure and acceleration sensors located on the specific side of the car. For redundancy each of the systems, together with the needed sensors, are duplicated. To ensure independence between duplicates, constraints are added to the systems. They restrict their mapping to ECUs in the technical perspective. Constraints are formalized using the pattern based RSL. For the LSI1 and LSI2 systems this constraint looks like: LSI1 and LSI2 shall not be mapped together on same ECU-Instance 30/ 156
Architecture Modeling The constraint consists of a constant phrase (denoted by the bold text) and a left and right side. On the left side a conjunction of elements from the logical perspective are named (here: LSI1 and LSI2). Their mapping is constraint with respect to the element(s) from the technical perspective on the right side of the pattern (here: ECU-Instance). Based on these constraints other constraints for the connected sensors of each system can be derived. To ensure independence of the duplicated systems, each of their sensors must not be shared between them. In our example sensors are assumed to be a exclusive resources, so sharing is not allowed and no additional independence constraints are needed. Technical Perspective On the technical perspective the airbag systems needs to be allocated to ECUs and sensors. In our example we have four ECUs available, which are all of the same type “ECU Type”. Each ECU instance has a series of ports with an incoming direction modeling the possibility to connect equipment to them. In the same way acceleration and pressure sensors are modeled. They have a base type (one for acceleration and one for pressure sensing) and ports with an outgoing direction. All ports are typed by a PortSpecification. Together with the direction information it is therefore known which components can be connected. Such a connection between an ECU and a sensor represents a cable in the airbag example. It is also possible to model the cable explicitly with a separate component, which allows to specify additional properties, but in our example the representation by connections is sufficient. The mapping between elements of the logical and technical perspective can be done by adding links to the model. This allocation can be used to formulate a mapping problem or a solution. By allocating a logical sensor element on a technical sensor type (e.g. “Acceleration Sensor Left Type”) the mapping problem to find a suitable sensor instance of this type is specified. Alternatively the allocation target can already be a instance in which case the allocation models a concrete mapping, i.e. a mapping solution. In our airbag system the sensor systems are mapped to the corresponding sensor type in the technical perspective. This way a problem space is created. Since two pressure and acceleration sensors are available on each side the optimal one depends on the allocation of the systems to the ECUs. Also the computational parts can be executed on any of the available ECUs. Thus the allocation of the LSI, RSI and FI systems to ECUs is an open mapping problem. A solution to such a problem must fulfill all needed sensor inputs of the subsystem and the independence constraints associated with the system. By connecting ports of sensors with ports of an ECU a cable is added to the system. To be able to calculate the resulting cable length the geometrical perspective is used. Geometrical Perspective The geometrical perspective is used to organize the information regarding the position of the ECUs, the positions of the Sensors and the distance between these elements. The distance is determined by the actual cabling in the car, i.e. that the distance is influenced by the physical environment of the vehicle. Some cable can be put through the roof of the vehicle directly while other cables have to be put through the vehicle chassis. This can lead to a very different cable length from two nearby sensors to an ECU a fact which underline the importance of the automation of the optimization process, since the obvious solutions are most probably not the optimal ones. Model Processing As stated above the allocation links between the logical and the technical perspective are capable of creating an allocation space. The geometrical perspective provides the information to evaluate the different possibilities to solve the allocation. Furthermore the 31/ 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: ShapeCompositionOperator intersecti
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

Create successful ePaper yourself

Delete template?

Save as template?