D2.3 Analysis and back-propagation of properties for multicore systems - Initial Version

Transcription

1 G u a r a n t e e d C o m p o n e n t A s s e m b l y w ith R o u n d T r ip A n a l y s i s f o r E n e r g y E f f i c i e n t H ig h - int e g r i t y M u lt i - c o r e S y s t e m s Project Number D2.3 Analysis and back-propagation of properties for multicore systems - Initial Version Version November 2014 Final Public Distribution MDH, INT, UNIFI, UPD Project Partners: AENSys, Aicas, Atego, Budapest University of Technology and Economics, Critical Software, EADS, Intecs, ISEP, Maelardalens University, OTG Solutions, SINTEF, Thales Communications & Security, The Open Group, University of Florence, University of Padova Every effort has been made to ensure that all statements and information contained herein are accurate, however the Partners accept no liability for any error or omission in the same Copyright in this document remains vested in the CONCERTO Project Partners.

2 DOCUMENT CONTROL Version Status Date 0.0 Initial coarse-grained document structure 08 Aug 2014 Added contributions regarding CHESS review and proposal for 29 Sept changes 0.2 Added contribution about dependability profile, modelling of partitions, 20 Oct 2014 modelling of socio technical system. Overall check performed. Version issued for internal review. 1.0 Final issue with comments from internal reviews (made by BME and Atego) addressed. 03 Nov 2014 Page ii Version November 2014

3 TABLE OF CONTENTS List of Figures... iv List of Tables... iv List of Abbreviations... v Executive Summary... vi 1 Introduction Review of the CHESS modelling language Support for View Definition Modelling the real time Timing annotation Real time analysis Modelling the dependability CHESSML modification cross domain System Model Data flow Socio-technical systems Component Model Data flow Inter-components bindings scenarios Hierarchical Components Events Operational Modes Dependability\Safety Model The new CHESS dependability profile Instance-level modelling of extra-functional properties Platform and Allocation Models (Deployment Model) Modelling allocations for each operational mode Modelling extra functional properties for operational modes Modelling Partitions Analysis model CHESSML modification domain specific Petroleum The extension planned to support socio-technical systems modelling are currently applied to the petroleum domain (see D3.2). No further extensions are currently formalized in the CHESSML for the petroleum domain Automotive Safety Integrity level Coverage of CONCERTO metamodel derived requirements Conclusion References A. An introduction to the CHESSML profile B. CONCERTO Dependability Profile November 2014 Version 1.0 Page iii

4 LIST OF FIGURES Figure 1: Sequence diagram representing inter-component bindings... 6 Figure 2: Modelling Signals... 7 Figure 3: Modelling Operational Modes (source MARTE spec.)... 8 Figure 4: CSD and its corresponding composite instance model Figure 5: modelling Allocations constrained to OperationalModes Figure 6: Initial extension for safety integrity level modelling support Figure 7: CHESS model and views predefined structure Figure 8: Interfaces Figure 9: ComponentTypes Figure 10: ComponentType s provided and required ports Figure 11: CHESS CompoentImplementation Figure 12: Intra-component binding Figure 13: CHESS ComponentImplementation instances Figure 14: CHESS timing annotation Figure 15: CHESS Instance Model Figure 16: CHESS deployment model Figure 17: Timing properties resulting from the analysis Figure 18: Dependability information annotated HW components Figure 19: SBA analysis context Figure 20: FPTC specification Figure 21: Results of the FPTC analysis Figure 22. Proposal for the CONCERTO dependability conceptual model LIST OF TABLES Table 1 - WP4, WP3 cross domain metamodel reqs and their coverage at M Table 2 - WP4, WP3 domain specific metamodel reqs and their coverage at M Page iv Version November 2014

5 LIST OF ABBREVIATIONS ASIL CHESSML CSD DSL FLA FPTC IMA PIM PSM QoS SBA Automotive Safety Integrity Level CHESS Modelling Language Composite Structure Diagram Domain Specific Language Failure Logic Analysis Failure Propagation and Transformation Calculus Integrated Modular Avionics Platform Independent Model Platform Specific Model Quality of Service State-Based Analysis 3 November 2014 Version 1.0 Page v

6 EXECUTIVE SUMMARY This document reports on the work conducted in WP2 as first iteration of the definition of the modelling language capable to express system, software and hardware multi-core architectures, together with non-functional properties for analysis and back-annotation. The findings discussed in this document rely upon the understanding of industrial requirements captured in WP1 and in particular upon the corresponding elaborations performed in WP2, WP3 and WP4. This document considers the results of the CHESS project as baseline and then starts identifying the modifications and the extensions that are needed in the CHESS modelling language to satisfy the CONCERTO project requirements. Page vi Version November 2014

7 1 INTRODUCTION This report describes the modifications required for the CHESS modelling language to support the CONCERTO needs for what regards the modelling, analysis and back propagation of the analysis results. In particular, current results coming from WP3 and WP4 have been taken into account. The structure of the document is the following: first the reviews of the CHESS modelling language, as resulting from the CHESS project, is addressed in section 2; then in sections 3 and 4 initial proposals for the extensions of the CHESS modelling language for the cross and specific domain needs respectively are discussed. The current coverage of the CONCERTO requirements with respect to the updated CHESS modelling language (as presented in this document) is discussed in section 5. 2 REVIEW OF THE CHESS MODELLING LANGUAGE The CHESS modelling language (CHESSML) is considered as the baseline for the CONCERTO needs. This section reviews the current version of the CHESSML, i.e. the one resulting from the CHESS project, in order to better identify a more stable and suitable baseline to be adopted in CONCERTO. The CHESSML specification, as metamodel\uml profile, is described in the CHESS deliverable D2.3.2 [CHESSD232]. Basically the CHESSML restricts and extends the SysML, UML and MARTE OMG standards to support: view definition, modelling of PIM entities, modelling of the hardware platform, modelling of timing related information (at PIM and PSM level), modelling of dependability information (at PIM and platform level), modelling of analysis scenario, modelling of PSM entities, back propagation of analysis results (at PSM and PIM level). The reader can refer to annex A for a quick introduction to the CHESSML illustrating the aforementioned support. In the remainder of this document the term component type is used to refer to a classifier of a set of component instances, in the sense of the object-oriented paradigm, while the terms ComponentType and ComponentImplementation are used to refer the 3 November 2014 Version 1.0 Page 1

8 corresponding entities (i.e. stereotypes of the UML Component) defined in the CHESS component model (see CONCERTO D2.2). 2.1 SUPPORT FOR VIEW DEFINITION In CHESSML a view corresponds to a stereotyped package, i.e. an UML container allowed to own all the entities that belong to the given view. It is worth to remember that a view-package can be defined as the sum of distinct sub-views, the latter acting upon the same package of the parent view; e.g. this is the case for the CHESS component view-package which is actually the overlapping of two distinct sub-views: the functional and extra functional views. Regarding the support for views definition in CHESSML, no extension is currently planned in CONCERTO. The approach selected in CONCERTO is to build a dedicated meta-model for views specification 1 definition; in particular, for each view, the meta-model will allow to formalize the permission rules (e.g. read-only, read-write) to be applied at modellingtime on the entities of a given domain specific language (DSL), as defined by the view specification itself. The meta-model will be implemented in Eclipse and a framework will be developed on top of it to offer a DSL-independent support for views definition and usage to be integrated with the Eclipse Papyrus UML editor. Then the framework will be instantiated to implement the views required by CONCERTO (as documented in CONCERTO D2.1), together with the editing rules upon the CHESSML entities. 2.2 MODELLING THE REAL TIME Timing annotation Regarding real-time modelling and back-propagation support, CHESSML basically relies on the usage of a subset of the MARTE language which allows the timing decoration of component s ports at PIM level. MARTE (in particular the RtSpecification 2 stereotype) has been extended in CHESS to support real-time annotation of operations exposes through provided ports at component instance level; in fact MARTE allows to attach real time information like WCET, thread activation pattern (e.g. sporadic, periodic) to a given operation of a component type, while timing information is proper of (and as to be differentiate for) each single component instance. The aforementioned limitation of MARTE was reported to the MARTE OMG team 3 and it will be fixed in the next version of the MARTE OMG release. An open question in CHESSML is the following: the decoration of component s operations exposed through provided ports makes it possible to address operations having public visibility only; in fact only public operations are visible through a provided port. E.g. in this way cyclic operations have to be defined public in order to be decorated, while a cyclic operation does not need to be visible from the external 1 View specification is also known in literature as viewpoint. E.g. from the SysML: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns 2 Defined in the MARTE::HLAM sub-profile 3 OMG Issue Page 2 Version November 2014

9 components. To overcome this limitation, it should be possible to extend the decoration of real-time information to private operations of a given component instance (see section 3.5 for a further elaboration) Real time analysis Another MARTE customization available in CHESS regards the way analysis results are available in the model (by back-propagation). The MARTE profile makes a clear distinction how HW, SW resources and the information resulting from a particular analysis are modelled, and uses different stereotypes for these different aspects. In CHESS some parts of this information have been collapsed into the extended RtSpecification stereotype; in fact the latter is used to provide timing properties of the SW operations-resources (e.g. their activation kind, like periodic, sporadic, and its deadline) and to attach data coming from the analysis (e.g. the worst case response time and blocking time for the given operation) (see Annex A); this was done in CHESS because MARTE does not allow to have information resulting from the analysis attached to port-operation. In order to provide a better compliance with the MARTE standard, one of the goals in CONCERTO is to review its analysis result storage approach so that the analysis context and results can be modelled separately from the system resources, as in MARTE. Finally, in order to continue representing the real time analysis results associated to the port-operation a new dedicated analysis view will be developed and evaluated. More in detail, the proposed CHESSML modification is to leverage the role and use of the instance specification entities of UML, and so of the instance model. In UML the instance model allows to represent the entities which are available in a given running system; it is typically derived starting from the static part of the model comprising the component and composites structure diagrams; the CHESS toolset already supports the automatic derivation of the instance model. The idea is to use (and extend if needed) the UML instance model to allow representing instances of components with their operations, so to be able to model real time properties and analysis results at instanceoperation level by using MARTE stereotypes. It is worth noting that the availability of instance-operations in the instance model, also the ones with private visibility, would allow the decoration of them; this would overcome the limitation expressed in section about cyclic operations having public visibility. The reader can refer to section 3.5 for a further elaboration of the intended usage of the instance model in CONCERTO. 2.3 MODELLING THE DEPENDABILITY Regarding dependability, CHESSML comes with a dedicated dependability profile [CHESSD232]; the parts of the dependability profile useful to represent error models, state-based and failure propagation information is reviewed and extended in CONCERTO according to the results coming from the WP3. The other constructs available in the CHESS dependability profile will not be considered here given that they are out of scope for CONCERTO. The elaboration about the extension of the dependability profile is provided in section November 2014 Version 1.0 Page 3

10 3 CHESSML MODIFICATION CROSS DOMAIN This section addresses the cross-domain model-level support added to the CHESSML to support the CONCERTO needs. 3.1 SYSTEM MODEL Data flow The modelling support discussed in this section is offered through the System View, which basically reuses and tailors the SysML standard. SysML support to the modelling of data flow is introduced in CHESSML. This is to allow modelling of data-flow at system level, e.g. useful to enable expression of dependability properties and to allow dependability analysis at system level Socio-technical systems Extensions to the CHESSML are introduced to address the modelling of socio-technical systems, the latter discussed in CONCERTO deliverable D3.2. To enable the modelling of socio-entities, two additional kinds of composite components are introduced in the CHESSML: human and organizational. According to the CONCERTO FLA: human beings are modelled as composite components comprising their sensorlike and actuator-like functionalities (as atomic components); human failures can be represented as an internal component, named accordingly to the category. Input ports of the human composite component should be connected to appropriate input port of the logical (or sensor-like) component, and the output of the action-related component should be connected to the output port of the human component. Several logical components can be connected to actionrelated component, and only one action-related component should be allowed for one human component. Organizational composite components should be connected to human composite components using appropriate ports to capture organizational influences on human behaviour. Human composite components are then connected to technical (composite) component. So the following stereotypes are added in the CHESSML in the system view (as specialization of the SysML Block entity): Human Organizational Technical. As documented in D3.2, CONCERTO FLA is based upon the CHESS Failure Propagation and Transformation Calculus (FPTC) formalisms and analysis. Page 4 Version November 2014

11 To allow failure logic analysis to be applied to socio-technical systems, the CHESS language constructs already available to support FPTC expressions for software and hardware components become also applicable to the socio-technical systems entities. In detail, FPTC can be used to assign a FPTC expression to human, organizational and technical blocks and related sub-blocks, while FPTCSpecification can be used to model a given failure (late, early, omission, etc.) in input or output to a given block s port. Furthermore, as required by the CONCERTO FLA, the application of FPTC is extended to connectors, to allow modelling of failure of blocks interactions, and to block and connector instances, to allow the refinement of FPTC specification at block instance level. 3.2 COMPONENT MODEL Data flow This section addresses the new modelling features introduced in CHESS through the Component View. Data flow is introduced in the ComponentView as supported by MARTE through the FlowPort entity (similar to the SysML support available in the SystemView). In CHESSML FlowPorts are not allowed to be decorated with timing information. Data flow in the component model is introduced to enrich the support for functional and dependability modelling. For example, in a preliminary phase of the software design - where typically dependability analysis applies - only the data flow is available for the entities under design, while the provided and required interfaces and service ports (i.e. ports providing and requiring operations) are still to be defined. In this case the usage of flow ports can be used to allow preliminary dependability\safety analysis, like failure propagation, without the need to introduce and consider provided and required interfaces\ ports for the components Inter-components bindings scenarios Inter-components bindings are functional collaboration scenarios, i.e. call operations flows between interacting component instances (see CONCERTO D2.2). UML sequence diagrams are introduced in CHESSML to support the modelling of inter-components bindings; see Figure 1 for an example, where component instances are represented together with the sequence of the operations calls between them. 3 November 2014 Version 1.0 Page 5

12 Figure 1: Sequence diagram representing inter-component bindings For a given system under design, different inter-components bindings can be provided, one for each particular collaboration scenarios to be represented (for instance, one for each operational mode, see section 3.3). The main goal of this extension is to enrich the functional behaviour specification, available in the functional view, and provide additional analysis techniques, in particular end-to-end response time analysis. The inter-components binding scenario complements the intra-component binding information already available in the CHESS component model (see CONCERTO D2.2) and represented by using UML activity diagrams. CHESSML intra-component bindings are represented by activity diagrams attached to component s operations (so all the instances of the same component inherit the same specification of intra-component binding); the activity diagram models the sequence of internal or external operations calls, the latter invoked through the required ports of the component itself. So intracomponent bindings are modelled for a component-operation in isolation and do not consider external components. In order to avoid inconsistencies in the model, the set of call operations modelled in the intra-component and inter-components bindings, and so activity and sequence diagrams, have to be consistent Hierarchical Components Hierarchical components are introduced in the CHESSML. In particular UML composite structure diagram can be used to model the decomposition of a given ComponentImplementation into a collaboration of functional ComponentImplementation instances: each component instance is typed with a ComponentImplementation which in turn can be decomposed by using a different composite diagram. 4 In the intra-component binding (sequence diagram), supposed to have a call to an operation Op upon an instance of component C which in turns calls another operation OpReq; then the call of the operation OpReq must be defined in the intra-component binding associated to operation Op of component C as well. Page 6 Version November 2014

13 3.2.4 Events So no UML extension are needed in the modelling language to support the current candidate top-down and bottom-up process for hierarchical components design as discussed in CONCERTO D2.2 (Solution 3, pag. 17). Events as elaborated in CONCERTO D2.2 are introduced in the CHESS modelling language by using the UML Signal. UML Signals supports generalization and subtyping (i.e. it is possible to have hierarchies of events) and they can either carry parameters or be parameter-less, as required by D2.2. Moreover, UML defines that the sender of a Signal will not block waiting for a reply but continue execution immediately which is compliant with the constraint of the CONCERTO component model which does not allows sender-side operations to be blocking. The possibility to have MARTE output/input FlowPorts typed by a single Signal is introduced in the CHESSML for the ComponentType and ComponentImplementation 5, so to model the emission/reception of events, i.e. what is called in the CONCERTO component model event emitter/receiver ports. In addition, out flow port can be bound to multiple in flow ports (or even none), as many as the components that are interested in the notification. The information about the event that can be emitted by the implementation of a given operation is modelled in the activity diagram representing the intra-component binding of the operation itself; in particular the UML SendSignalAction has to be used in the activity diagram. To model that a ComponentType or ComponentImplementation can react to a given event, the UML Reception construct has to be attached to the component; the Reception allows specifying the behaviour of the component to be processed when the given signal arrives. Figure 2 shows the modelling of Signal and Reception in UML; in particular Receptions is shown in the Component s compartment using the same notation as for Operations with the keyword «signal». Figure 2: Modelling Signals 5 The same support can be added in the system view for the block entities if needed. 3 November 2014 Version 1.0 Page 7

14 As additional constraint from the CONCERTO component model, the operation tagged with Receipt, can only be marked protected or unprotected in the extra-functional view. 3.3 OPERATIONAL MODES Operational modes are introduced in the CHESSML. As stated in the MARTE specification: An operational mode can represent different things: An operational system (or subsystem) state that is managed by reconfiguration mechanisms (e.g., fault-tolerance management middleware) according to fault conditions. A state of system operation with a given level of QoS that can be handled by resource management infrastructures (e.g., middleware that assign resources at run time according to load demand, timing constraints, or resource usage). A phase of a system operation (e.g., starting, stopping, launching, in a missioncritical aerospace system). Operational modes can be defined for the given system under design by using MARTE stereotypes, and in particular the stereotyped modebehaviour state machine, together with mode states and mode transitions (see in Figure 3). Mode transitions can be added in the state machine in response to an Event (see section 3.2.4) to model how a given change of mode is activated in the system. The modebehaviour state machine can be defined at system, component or hardware level. Currently in CHESSML we assume that only one modebehaviour can be provided for a given CHESS model. Figure 3: Modelling Operational Modes (source MARTE spec.) Page 8 Version November 2014

15 3.4 DEPENDABILITY\SAFETY MODEL The modelling support discussed in this section is offered through the different dependability views available in the system, component and deployment views (see CONCERTO D2.1) The new CHESS dependability profile According to result of WP3, the needs for modifications of the CHESS dependability profile have been identified in order to: improve the support for dependability modelling and analysis needs, improve the integration between the two analysis techniques State-Based Analysis (SBA in the following) and Failure Logic Analysis techniques (FLA in the following). The proposed extensions are based on the following requirements coming from CONCERTO D3.2 (see D3.2 for a deeper elaboration): In CHESSML it shall be possible to define different (custom) failure classifications, to be used in different models, or for different components. In the current CHESSML failure classifications are associated with component ports, i.e., the failures that are assumed to occur on that port can be specified. Ports connected together by a connector should use the same classification with respect to failures. In CHESSML, it should be possible to use annotations for state-based and for failure logic analysis together More in general, in CONCERTO ML, it should be possible to define the failure behaviour of a component at different levels of details: o No annotations The component does never fail spontaneously (i.e., no internal faults). If an incoming failure is received from another component, then it is transmitted as it is. o FLA annotations only The component does never fail spontaneously (i.e., no internal faults). If an incoming failure is received from another component, then it is transmitted according to FLA rules. o SBA annotations (failure rate/repair rate) o SBA annotations + FLA annotations o Error Model 3 November 2014 Version 1.0 Page 9

16 In the error model it shall be possible to define several ErrorStates, which define the behaviour of the component different from the nominal Healthy state (the InitialState). In the error model the distinction between Error and FailureMode as in the current CHESSML is no more needed. For any ErrorState it shall be possible to define which failure mode affects the ports owned by the component. The reader can refer to Annex B for an elaboration of the implementation of the aforementioned requirements, to be included in the CHESSML as replacement\enhancement of the previous CHESS dependability profile. 3.5 INSTANCE-LEVEL MODELLING OF EXTRA-FUNCTIONAL PROPERTIES The current section gives an overview on the extensions of the CHESSML on instancelevel modelling support. The instance-level modelling support is available in the system, component and deployment views. In other words the instance model applies to all the different architectural modelling levels: system, software and hardware. The CHESSML resulting from the CHESS project makes use of the UML composite structure diagram (CSD) to model instances and extra functional information for them; there can be some limitation while using CSDs to model instances, especially if hierarchies of instances, i.e. instances owning sub-instances, have to be considered, together with its ports and extra functional decoration 6. This limitation would even be relevant in CONCERTO where decomposition of components and hierarchical instances and their extra functional annotation are considered. The proposal in CONCERTO is to rely much more on the usage of the UML instance model. In UML there is not a specific view\diagram for the instances, they are modelled through the class diagram with a very basic notation; a kind of composite object diagram is available in the UML standard itself (see in Figure 4) but just as example, it is not formalized (and so UML tools do not support it); as counterpart, instance models are particularly of interest in the kind of systems addressed in CONCERTO where e.g. decoration of extra functional properties naturally apply at this level. 6 Composite structure diagram allows to model instances but in the context of a classifier, i.e. given a classifier, like a component, it is possible to model the instance that are created when an instance of the component itself is created. So only one level of decomposition; clearly composite structure diagram can be composed together, so if an instance A inside a composite diagram is typed by a component B with in turn has a composite diagram, then it is possible to see A as decomposed by the instances owned by B. However there can be some limitation: imagine to have two instances of component B: then it is not possible to differentiate parameters of the instances owned by B for the different instances of B. Page 10 Version November 2014

17 Figure 4: CSD and its corresponding composite instance model The proposal in CONCERTO is to allow decoration of the UML instance model with extra functional properties. What we still have to define is how to render the instance model. Additionally, only a limited set of features are supported in the Papyrus UML editor (on which the CHESS editor is built). Within the project we might define an instance diagram editor equivalent to the CSD either a complete graphical editor following the concrete syntax defined in Figure 4, or use a simpler tree editor. Another point in favor of working with extra functional information at instance model level is that most of the extra functional information depends on the way components are allocated to hardware platforms, and the allocation is made at instance level, i.e., software component instances are the ones that are allocated to the platform (as already defined in CHESS). So the modelling steps to be performed in order to complete the design in the extra functional dimension are: 1. Create components (first ComponentType and then ComponentImplementation). 2. Create components CSDs for ComponentImplementations. 3. For the extra functional properties that can be expressed at this level, e.g., the dependability error model: attach extra functional information to the components and internals (the latter modelled in the CSDs) 3 November 2014 Version 1.0 Page 11

18 4. Create the instance model starting from what has been modelled with the component diagrams and their CSD s. 5. Use the instance model view to attach extra functional information for the instances or to override the extra functional properties eventually modelled in the step 3, if needed. In order to support step 5, the modelling language constructs used in CHESSML to model extra functional annotations at component level or in the CSD have to be made available in the CHESSML at instance level, i.e. in the instance model. Note that this support is particularly useful to complete the modelling of software component for what regards extra functional annotations, but it can also be adopted in the system view and platform specification view if useful to model blocks and hardware components properties at instance level. 3.6 PLATFORM AND ALLOCATION MODELS (DEPLOYMENT MODEL) Modelling allocations for each operational mode In case of a system with different operational modes it is possible to define different software to hardware allocations scenarios, one for each operational mode. In this case the MARTE Assign, already used to model allocations, can be constrained by the MARTE NFPConstraint construct, where the latter allow specifying the mode on which the given Assign has to apply. For example, in Figure 5 the allocation of the component instances to the processing resource CPU0 for only the NormalMode operational mode is modelled. Figure 5: modelling Allocations constrained to OperationalModes 3.7 MODELLING EXTRA FUNCTIONAL PROPERTIES FOR OPERATIONAL MODES In case of a system with different operational modes, through CHESSML it has to be possible to specify extra-functional properties of the system elements under design for Page 12 Version November 2014

19 each declared mode. Regarding temporal properties, MARTE defines a complex type 7 to allow the modelling of non-functional properties; in particular any property value (e.g., the period duration) can be expressed in MARTE by using a complex type which, in addition to the value, has a mode attribute which allows specifying the operational mode(s) in which the provided value is valid. 3.8 MODELLING PARTITIONS The CHESSML is extended in CONCERTO to allow the modelling of partitions. According to the latest results coming from WP4 presented in CONCERTO D4.6 about partitions support for IMA, a partition is defined in CHESSML as a UML Component stereotyped as FunctionalPartition. The stereotype contains extra-functional properties of the partitions (see section of D4.6) about budget, scheduling ordering and utilization. The allocation of component instances to partitions is modelled by using the MARTE stereotype <<Assign>> already used in CHESSML for assigning software components to hardware components (as showed in Annex A). Further support for modelling partitions will be added in CHESSML according to the upcoming results of WP4 and described in the final version of this deliverable. 3.9 ANALYSIS MODEL MARTE supports the modelling of the analysis context, where analysis context means: the system, SW, HW architectural entities to be taken into account by the analysis, with optionally their behaviour, the extra functional information attached to them, any other information to be given in input to the analysis, like for instance the property to be measured. Moreover the analysis context comes with additional properties for the backpropagation of analysis results, like the response time of a given cyclic operation. CHESSML already adopts the MARTE analysis context for what regards StateBasedAnalysis, FPTC and FI4FA Analysis. We are planning in CONCERTO to adapt the MARTE analysis context for all analysis techniques used within CHESSML. E.g. for what regards timing analysis, MARTE analysis contexts are used to specify the platform and workload needed for the schedulability and end-to-end analysis. The platform must comprises the instance models of the software and hardware components while the workload is represented by the extra functional information attached to the component instances; in case of the end-to-end analysis, the workload must also comprise the sequence diagram acting as the end-to-end scenario to be taken into account by the analysis (see section about inter-components bindings scenarios). 7 The NFP_ CommonType. Any property value (e.g. regarding real time, like period duration) can be expressed in MARTE by using a type which inherits from NFP_CommonType.. 3 November 2014 Version 1.0 Page 13

20 4 CHESSML MODIFICATION DOMAIN SPECIFIC 4.1 PETROLEUM This section addresses the cross-domain model-level support added to the CHESSML. The extension planned to support socio-technical systems modelling are currently applied to the petroleum domain (see D3.2). No further extensions are currently formalized in the CHESSML for the petroleum domain. 4.2 AUTOMOTIVE Safety Integrity level CHESSML is extended to be able to offer ASIL 8 decoration for: Requirements System level components (i.e. SysML Blocks) Software component (i.e. ComponentType and ComponentImplementaion) operations Hardware Components Picture below provides a sketch of the extensions to be introduced in the CHESSML. Figure 6: Initial extension for safety integrity level modelling support Basically, new kinds of requirements and blocks (extending the SysML ones) are introduced to support association of ASIL to requirements and system entities 8 Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO Functional Safety for Road Vehicles standard. Page 14 Version November 2014

21 respectively; an extension similar to AumotitveBlock will be introduced for the software component to support ASIL assignment to software entities. The final goal of the aforementioned extensions is to provide support at model level for ASIL inheritance, propagation and decomposition modelling automations, e.g. the latters as defined by the functional safety ISO automotive standard. 5 COVERAGE OF CONCERTO METAMODEL DERIVED REQUIREMENTS This section summarizes the current coverage of the CONCERTO derived requirements concerning the modelling language definition, i.e the metamodel\profile. The following tables are taken from CONCERTO D2.1 section 4 Plan for realization ; they summarize the requirements about the metamodel as derived by the end user requirement elaboration made in WP4 and WP3. The column Coverage has been added to trace what can be covered at M18 for what regards the modelling support, as discussed in this document. The uncovered requirements still need to be addressed, and needs inputs resulting from WP4 or WP3 elaboration. Table 1 - WP4, WP3 cross domain metamodel reqs and their coverage at M18 View WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 R9.1 (WP3.1) Data flow Covered SystemView System- DependabilityView (new sub-view, see R2.1_V1) R9.2 (WP3.1) Control flow To be clarified the need at model level. E.g.: for which analysis\model transformation this information would be used? R2.1 (WP3.1) Availability for system elements Partially covered. Dependability profile is now applicable at system level. R2.3 (WP3.1) Propagation information between system components Initially covered by the new dependability profile (possibly to be extended). 3 November 2014 Version 1.0 Page 15

22 View WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 R44.1 (WP3.1) R52.3 (WP3.1) R2.4 (WP3.1) Dependability attributes (with particular focus on safety/reliability/availability), such as failure rates, failure modes Initially covered by the new dependability profile (possibly to be extended). R9.3 (WP3.1) Specification of faults (for fault propagation analysis). R51.1 (WP3.1) Constructs for associating safety/risk properties with all types of components, including components that represent physical equipment or human/organizational elements Covered. Partially covered. R39.1 (WP3.1) ASIL as system block property. Covered R61.1 (WP3.1) Argumentation of independence for the redundant elements R2.2 (WP3.1) Redundancy and fault-tolerance mechanism Component- FunctionalView R1.1 (WP4.1) Modes of operation for software components R95.1 (WP4.4) R9.2 (WP3.1) Attributes to define expected flow between inputs and outputs of components R95.2 (WP4.4) Policies that govern valid information flows between component inputs and outputs shall be defined. R89.1 (WP4.4) Attributes to define preconditions that must be respected before performing certain actions. Covered Covered (intracomponent bindings). Still under investigation if further support is needed here. R9.1 (WP3.1) Data Flow Covered Component- ExtraFunctionalView R6.2, R94.1 (WP4.1) Schedulability attributes for software components such as period, deadline, WCET, offset and jitter. Covered Page 16 Version November 2014

23 View WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 R26.1 (WP4.1) Buffers, semaphores and their nonfunctional properties (like, size, queuing policy) and services to manipulate these resources (intra and inter partition O1.1 (WP4.1) Parallel tasks. Parallel activities can be introduced IN CHESS-ML by extending the activity diagram already used for the modelling of the intra-component binding scenarios. In particular the possibility to add fork and join nodes would be enough. What is still under discussion and evaluation regard the clarification of the PSM support for what concern the generation of parallel tasks. R94.2 (WP4.4) Handler associated with deadline miss R5.1 (WP4.4) Task utilization R80.1 (WP4.4) Attributes to specify access policies, as well as to attach these policies to components R44.1 (WP3.1) Dependability attributes (with particular focus on safety/reliability/availability), such as failure rates, failure modes R9.3 (WP3.1) Specification of faults (for fault propagation analysis). R39.1 (WP3.1) ASIL, as property for software component Covered Covered Covered R61.1 (WP3.1) Argumentation of independence for the redundant elements 3 November 2014 Version 1.0 Page 17

24 View WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 R34.1 (WP4.1) Extra-functional properties compatible with the timing properties required by the ASTRIUM computational model R4.1 (WP4.1) Hard or soft timing constraint. Partially covered. R78.1 (WP4.1) Usage of MARTE to define hardware specific concerns Partially Covered R73.1 (WP4.1) Execution nodes, containing single core or multi-core processors, R6.1 (WP4.1) Multi-core schedulers for SMP and heterogeneous systems R6.2 (WP4.1) Schedulability attributes for hardware components. Multi-core schedulers for SMP and heterogeneous systems Deployment- PlatformSpecification View R6.4 (WP4.1) R70.1 (WP4.4) Computational hardware resources (processor, memory, specific resources) for single and multi-core systems. Combination of cache(s), memory access and communication busses. R35.1 (WP4.1) Fix priority scheduler, time-table driven scheduler and the composition of both of them (two-level scheduler). R23.1 (WP4.1) Configuration information for the underlying platforms R35.2 (WP4.1) Processing nodes and cores decorated with schedulers R23.2 (WP4.1) Configuration information assigned to the nodes of the platform architecture. R5.1 (WP4.4) CPU, system utilization attributes. Partially covered R25.1 (WP3) Hardware devices like sensors, mobile local hubs R25.2 (WP3) network services to represent, for example, centralized decision support systems Page 18 Version November 2014

25 View WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 R44.1 (WP3.1) Dependability attributes (with particular focus on safety/reliability/availability), such as failure rates, failure modes R9.3 (WP3.1) Specification of faults (for fault propagation analysis). Covered Covered R39.1 (WP3.1) ASIL, as property for hardware element Covered R61.1 (WP3.1) argumentation of independence for the redundant elements R73.1 (WP4.1) allocation of the software components to the execution resources on execution nodes, containing single core or multicore processors Covered R71.1 (WP4.1) Core reservation for software components. R46_V1 R72.1(WP4.1), R72.3 (WP4.1) TLC specific hardware (MARTE support with respect to the TLC relevant properties shall be investigated) Processor affinity for (critical) software components. Deployment- Allocation View R70.2 (WP4.4) Configurations of the memories by defining per-task memory budgets. R71.3 (WP4.1) Core reservation Table 2 - WP4, WP3 domain specific metamodel reqs and their coverage at M18 View Domain WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 3 November 2014 Version 1.0 Page 19

26 View Domain WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 RequirementView Automotive R39.1 (WP3.1) ASIL, as requirement property. Covered SystemView SystemView- ExtraFunctionalView SystemView- ExtraFunctionalView Petroleum R53.1 Barriers, Dynamic properties of barriers Petroleum R50.1 Risk Petroleum R50.2 Computational model/formula at design time for aggregation of safety properties Initially covered by the socio-technical system profile (possibly to be extended). Component- ExtraFunctional View Deployment- PlatformSpecification View Deployment- PlatformSpecification View Automotive R43.1 Telecare R23.1 (WP3.1) Telecare R23.2 (WP3.1) Specification of application level failure code and diagnostic services provided by the run time environment Telecare domain specific configuration information Configuration information assigned to the nodes of the platform architecture Deployment- PlatformSpecification View Telecom R18.1(WP3.1) Mobile device domain-specific configuration Deployment- PlatformSpecification View Deployment- PlatformSpecification View Automotive R40.1 (WP3.1) Automotive R85.1 (WP3.1) Assignment of can data bases (DBC) to a CAN networks CAN, LIN, FlexRay busses/protocols Page 20 Version November 2014

27 View Domain WP4, WP3 refined Requirements with Category Metamodel to be managed through the view Metamodel information to be managed through the view Coverage at M18 Deployment- Allocation View Telecare R25.4 (WP3.1) Dynamic reconfiguration of allocations As multiple allocations can be defined for different modes, we think we might use this feature to model the possible dynamic reconfiguration scenarios. 6 CONCLUSION The current document reports the initial extensions currently foreseen to the original CHESS modelling language. Several modifications have been identified to start covering the CONCERTO requirements along with some limitations of the CHESSML, where proposals for changes have been defined. Additionally, new extensions needed for CONCERTO have been discussed like: (i) modelling of socio-technical system, (ii) the new dependability profile, (ii) the modelling concepts of safety integrity levels, (iii) defining partitions and (iv) operational modes. The complete definition of the new CHESSML covering the CONCERTO requirements will be finalized in the next project period, taking into account the progresses made in WP3 and WP4, and documented in the second and final version of this deliverable. 7 REFERENCES [CHESSD232] D2.3.2 Multi-concern Component Methodology (MCM) and Toolset Version 1.0, 10 January 2012, CHESS Artemis Project Number (available at 3 November 2014 Version 1.0 Page 21

28 A. An introduction to the CHESSML profile This section provides an introduction to the main parts of the CHESSML, relevant for CONCERTO, as resulting from the CHESS project (no CONCERTO extensions), by illustrating some modelling examples. A basic knowledge of the UML standard is required. Figure 7: CHESS model and views predefined structure Following figures shows the definition of Interfaces and ComponentTypes. Figure 8: Interfaces Figure 9: ComponentTypes Figure 10 shows the definition or provided and required ports for a given ComponentType. Page 22 Version November 2014

29 Figure 10: ComponentType s provided and required ports Figure 11 shows the ComponentImplementations, where each ComponentImplementation realizes a given ComponentType. The ComponentImplementation inherits all the specification from the realized ComponentType, in particular ports with provided\required interfaces and operations; then ComponentImplementations can be used to provide implementation details, and then they can be instantiated and connected together. Figure 11: CHESS CompoentImplementation Figure 12 shows an example of intra-component binding (as of activity diagram) for the Produce operation implemented by the Producer_impl ComponentImplementation appearing in Figure 11; in particular it is modelled that the implementation of the Produce operation perform a call of Store and then Consume operations through required ports of Producer_impl (the On port field visible in the property editor in Figure 12 allows to specify the required port through which the operation call currently selected applies). 3 November 2014 Version 1.0 Page 23

30 Figure 12: Intra-component binding Figure 13 shows an example of ComponentImplementations instantiation and connection. The instances (in yellow in the figure) are represented as internal part of a root component, the latter representing the entire SW system under design. Each instance comes with the provided and required ports defined for the typing ComponentImplementation. Figure 13: CHESS ComponentImplementation instances Figure 14 shows an example of timing annotation for ComponentImplementation instances, by using RtSpecification decorating operations exposed through provided ports: Page 24 Version November 2014

31 Figure 14: CHESS timing annotation Figure 15 shows an example of instance model (tree-like view) derived from the model represented in Figure 14; in particular the instances of the software component are represented under the SwSystem_instSpec package. Figure 15: CHESS Instance Model Figure 16 shows an example of deployment, so about the platform specification; in this case only one computational resource is defined (in grey in the figure). Moreover the software to hardware component instances allocations are modelled using MARTE Assign constructs. Each Assign comes with from and to attributes through which the software instance (from) which is allocated to the hardware instance (to) can be specified. 3 November 2014 Version 1.0 Page 25

32 Figure 16: CHESS deployment model Figure 17 shows how the MARTE extended RtSpecification stereotype has been enriched with properties derived from the analysis (and stored by back propagation), like response time (respt) and blocking time (blockt). Figure 17: Timing properties resulting from the analysis Figure 18 shows hardware entities and ComponentImplementations enriched with dependability information (about stateful, stateless) useful for state-based analysis (SBA). Figure 18: Dependability information annotated HW components Figure 19 shows the State-Based analysis context used to run the state-based analysis. Page 26 Version November 2014

33 Figure 19: SBA analysis context Figure 20 shows how the information about FPTC rules (on the top of the figure) and failure types occurring on top level-input ports (on the left of the bottom figure) can be provided for ComponentImplementations at type and instance level, to allow FPTC analysis. Figure 20: FPTC specification 3 November 2014 Version 1.0 Page 27

34 Figure 21 shows how the results of the FPTC analysis about failure types occurring at output-port level are back propagated in the model. Figure 21: Results of the FPTC analysis. B. CONCERTO Dependability Profile This section describes the current proposal for the CHESS modelling language for dependability. The profile is based upon the conceptual dependability model presented in CONCERTO D3.2; the profile is defined here by taken into account the top-level requirements coming from WP3, which concern the possibility to apply dependability information at type and instance level and the possibility to use the dependability profile at System, Component and Deployment level (in particular for the latter for what regards HW platform entities). The proposal here is intended as replacement of the previous CHESSML Dependability Profile [CHESSD232]. The diagram of the dependability conceptual model is shown in Figure 22, as appearing in D3.2, then some further UML profile detail are provided in the following text. Page 28 Version November 2014

35 Figure 22. Proposal for the CONCERTO dependability conceptual model. FailureType (new entity in CHESSML) o Description: This element represents a type of failure (i.e., a failure mode) that is explicitly considered for the involved system. Different failure types may have different consequences on failure propagation. o Attributes Name : String [1] Description : String [0..1] UML::DataType FailuresClassification (new entity in CHESSML) o Description: A failure classification defines a partition of the failure modes associated with a component or service of the system architecture. Different failure classifications can be used for different parts/components of the system, in order to analyze in details their specificities. o Attributes 3 November 2014 Version 1.0 Page 29