Architecture Modeling - SPES 2020

More documents

Recommendations

Info

PortSpecification +part 0..* Env ironmentComponent +type RichComponentProperty 1 «isOfT ype» +component System +type «isOfT ype» 1 Architecture Modeling Port + isConjugated: Boolean 1 +port 0..* +component 1 RichComponent LogicalComponent +aspect SystemArtefact Aspect Requirement + rationale: String [0..*] SystemRequirement 0..* +stakeholder 0..* Stakeholder Figure 3.7: Meta-model integration of the concepts for specifying the logical perspective Activities and their performing actors of the operational perspective can be allocated to EnvironmentComponents. This allows to refine the behavior at the interfaces of the system. The concept System denotes a component, that defines the system boundaries. Thus, such a component should exist at most once per abstraction level. If a System is used as part in the context of another LogicalComponent, then the other parts should be typed by EnvironmentComponents. Allocating LogicalComponents to elements of a technical perspective realizes a software-hardware partitioning and describes how an underlying platform executes the LogicalComponents. However this does not mean that a designer cannot express that partitioning in advance in a logical perspective. For example considering AUTOSAR [9] an application is modeled as a composition of interconnected software components. On the design entry in AUTOSAR these software components are connected by means of a so called Virtual Functional Bus that abstracts from system topology, available resources (e. g. electronic control units) and communication media. Thus, in scenarios where software-hardware partitioning shall be decided but the allocation to platform resources is left open, one may explicitly model software- as well as hardware-specific components in the logical perspective. 3.2.3.1 Communication Refinement The logical perspective of the system is not concerned with the specification of properties of the target platform hosting the logical component architecture. Especially it is also not decided how the logical components are deployed. However a logical perspective of a system has to take into account, that the communication between components will later on be mapped to a distributed communication infrastructure (like e. g. a CAN-Bus or AFDX) or to a communication local to a computing node. LogicalComponent part1:Controller part2:Actuator ... p1 p2 com:Comm Comm C3 Figure 3.8: Enabling logical communication refinement in the logical perspective ... 20/ 156
Architecture Modeling The semantics of HRC is defined such that behavior is always part of a RichComponent or specializations thereof. The connection of ports (syntactically described in Section 3.3.2.2) is semantically interpreted as the identity of the behavior observable at the connected ports. So if in the example sketched in Figure 3.8 the ports p1 and p2 would have been directly connected, then any event or data occuring at port p1 is at the same time observed at port p2. Thus, in order to be able to specify assumptions about communication latencies from a real-time aspect, one needs at least conceptionally a LogicalComponent. For that component contracts can again be used for the specification of the different aspects of the logical communication, e. g. expected latencies or failure hypothesis. Though conceptionally logical communcation has to be represented as a RichComponent, the user-representation can be different. For example a UML-profile based on the architecture meta-model, can introduce a stereotype, which is applicable to uml::Connector and is mapped to the concept of LogicalComponent. 3.2.4 Technical Perspective In the technical perspective the electric/electronic architecture of the system is specified, which comprises mechanical and hydraulic components controlled by a network of control units, that the logical components shall be allocated to. The electronic control units may be softwareprogrammable hardware components or application specific integrated circuits (ASICs). Mechanical components are for example cams, shafts, switches and relays. Hydraulic components include for example valves and cylinders. The concepts provided for describing a view corresponding to the technical perspective are more specialized than those provided for modeling an operational, functional or logical perspective. That is because it is intended to apply dedicated analysis techniques for checking satisfaction of contracts (cf. Section 4.3) based on models of the technical perspective. In Section 5.1.3.5 an example is presented how the concepts described in this section can be used to model a technical view. +part 0..* RichComponentProperty «isOfType» +component 1 +type 1 RichComponent TechnicalComponent +aspect SystemArtefact Aspect Requirement + rationale: String [0..*] SystemRequirement 0..* +stakeholder 0..* Stakeholder Figure 3.9: Meta-model integration of the concepts of TechnicalComponents The architecture meta-model provides concepts to specify the technical perspective of a system by means of TechnicalComponents (see Figure 3.9). While we do not provide specialized concepts in the meta-model for mechanical or hydraulic components, their aspects however can still be specified by means of contracts. That allows a characterization of their dynamics and to assess whether requirements on functions are fulfilled by the mechanical or hydraulic components and the electronic components controlling them. In SPES the focus is on software-intensive systems. Therefore the meta-model incorporates specialized concepts to describe the resources of a network of electronic control units, which 21/ 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: 3.2.2 Functional Perspective Archit
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?