RÉGIS CASTERAN – SYSTEMS AND SOFTWARE ENGINEERING DOMAIN LEADER
09/23/2015 – V3
Sysml for embedded system
engineering
OVERVIEW PART 1 ● Background and challenges
PART 2 ● Using SysML at system level
PART 3 ● Using SysML at software level
PA...
PART 1
Background and challenges
4
Definitions
Embedded system
BACKGROUND AND CHALLENGES
A collection of hardware and/or software elements
organized to acc...
5
Definitions
Model
BACKGROUND AND CHALLENGES
A semantically closed abstraction of a system or a
complete description of a...
6
Background
Embedded system breakdown structure
BACKGROUND AND CHALLENGES
7
Background
Why and how modeling ?
BACKGROUND AND CHALLENGES
8
Challenges
Traceability between managements
BACKGROUND AND CHALLENGES
9
Challenges
Traceability between managements
BACKGROUND AND CHALLENGES
10
Challenges
Traceability between tools
BACKGROUND AND CHALLENGES
11
Challenges
SysML model verification
BACKGROUND AND CHALLENGES
Criteria Formality
level
Complexity Review type Instrumen...
12
Challenges
SysML model validation
BACKGROUND AND CHALLENGES
Validation
techniques
Development
state
Complexity Instrume...
PART 2
Using SysML at system level
14
Motivations
Stakeholder engagement in requirement management
USING SYSML AT SYSTEM LEVEL
15
Motivations
Automisation in architecture management
USING SYSML AT SYSTEM LEVEL
cmp Network principle
NET1_NODE1
NET2_N...
16
Motivations
Automisation in architecture management
USING SYSML AT SYSTEM LEVEL
«XSDcomplexType»
nodeType
«XSDelement»
...
17
Profiles
Principle
USING SYSML AT SYSTEM LEVEL
18
Profiles
Rationale
USING SYSML AT SYSTEM LEVEL
19
Profiles
Rationale
USING SYSML AT SYSTEM LEVEL
20
Profiles
Rationale
USING SYSML AT SYSTEM LEVEL
21
Patterns
Example
USING SYSML AT SYSTEM LEVEL
stm [Package] System state [System state]
Powered on
INITTESTINGFLASHING F...
22
Requirement management
Start with use cases
USING SYSML AT SYSTEM LEVEL
uc Maintenance Management
Embedded system
Class...
23
Requirement management
Specify scenarii
USING SYSML AT SYSTEM LEVEL
sd Process maintenance request from USB key
embedde...
24
Requirement management
Build architecture context with block diagram
USING SYSML AT SYSTEM LEVEL
bdd [Package] Maintena...
25
Architecture management
Split system functions
USING SYSML AT SYSTEM LEVEL
sd Process maintenance request from USB key
...
26
Architecture management
Split system interfaces
USING SYSML AT SYSTEM LEVEL
bdd [Package] Maintenance management [Maint...
PART 3
Using SysML at software level
28
Motivations
Stakeholder engagement in requirement management
USING SYSML AT SOFTWARE LEVEL
29
Motivations
Automisation in architecture management
USING SYSML AT SOFTWARE LEVEL
ibd [Block] SwcB_JWILL [SwcB_JWILL]
R...
30
Motivations
Automisation in architecture management
USING SYSML AT SOFTWARE LEVEL
31
Requirement management
Focus use cases on HW interfaces
USING SYSML AT SOFTWARE LEVEL
uc Software System Overview
ECU A...
32
Requirement management
Describe main features functional flow
USING SYSML AT SOFTWARE LEVEL
ibd [Block] Software compos...
33
Architecture management
Identify standard components
USING SYSML AT SOFTWARE LEVEL
«framework»
Application - BMW PDC L6...
34
Architecture management
Identify standard components
USING SYSML AT SOFTWARE LEVEL
«framework»
BMW PDC Common Modules
A...
35
Architecture management
Split main features functional flow between components
USING SYSML AT SOFTWARE LEVEL
sd Determi...
PART 4
Perspectives
37
Towards a new AGPS discipline offer: “Model Based Engineering for
Embedded System”
Principle
PERSPECTIVES
• Auditing cu...
Thank you !
Prochain SlideShare
Chargement dans…5
×

SysML for embedded system engineering - Academy Camp 2015

812 vues

Publié le

Presentation held during the Berner and Mattner Academy Camp 2015 about SysML usage for requirement specification and architecture description applied to embedded system engineering

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
812
Sur SlideShare
0
Issues des intégrations
0
Intégrations
14
Actions
Partages
0
Téléchargements
25
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • INCOSE: INternational Council On Systems Engineering
    ISO/IEC 15288: systems and software engineering: system life cycle processes

    Why our own definition for Embedded system ?
    Because there is no standardized definition
    To understand each other
    To share our discipline vision with our customers

    Embedded system is interfaced with:
    Sensors which provide Embedded system inputs
    Actuators which receive Embedded system outputs
  • ISO 24765: systems and software engineering: vocabulary

    Please reminder that a complete modelling of an embedded system is a myth !
  • On the right : project specification tree, as specified by INCOSE
    On the left: sysml decomposition of an embedded system in ALSTOM TIS
  • Two kinds of models:
    - interpretable: based on a modelling language, allowing to transform it into another language or model space
    - executable: embeds executable software code to compute discrete input values to discrete output values

    First model: not interpretable, not executable (comparison of brackets notation and without brackets notation in transition)
    Second model: more interpretable (based on UML notation), not executable (transition meaning ?)
    Third model: interpretable, executable
  • Architecture world relies on elements/interfaces decomposition and allocation
    Requirement world relies on needs refinement and allocation

    Challenge: how to link architecture artefacts to requirement artefacts ?
  • Solution :
    Architecture “satisfies” requirements (technical solution)
    Architecture “justifies” derived requirements (additional requirements to due to technical solution)
  • Example of a tool chain implementing this solution for VALEO:
    Requirement management is performed in DOORS
    Architecture management is performed in EA
    Standard design management is performed in Statemate
  • UPPAAL: UPPsala AALborlg university language

    Model verification criteria inherits from architecture verification criteria:
    Understandable:
    Scope, objectives, assumption of architecture are clearly defined
    Response navigation through the model elements/diagrams
    Clear traceability between model elements
    Completion:
    Fulfilment and traceability of all requirements
    Degraded modes and performances defined
    Range and precision justified
    Robustness
    Justification of derived requirements
    Justification of design pattern
    Justification of metamodeling and profiling usage
    Consistency
    Structural : instances vs classes
    Logic : sequence diagrams vs statemachine diagrams vs block diagrams
    Constraints
    Names
    Stability
    Baselining flexibility
    Scalability between variants
  • MDA : Model Driven Archicture

    Here an example of PIM for network description
  • Here the results of the MDA transformation of this network description into XML/XSD description
  • Everything can be modelized in SysML with a Block.
    So we need to specialize the block element for embedded system.
  • Why a “function block” ?
    - 1st argument: requirement satisfaction (functional view)
  • Why a “function block” ?
    - 2st argument: ibd of a “function block” is simplier than an “activity diagram”
  • Why a “function block” ?
    - 3st argument: structural view consistency with functional view

  • Please do not reinvent the wheel at each new project setup !

    Here is an example of a classical statemachine for embedded system.
  • First level of requirement traceability:
    A use case is not a function, but a “bundle of function” that “satisfies” a requirement (functional view)
    First level of interface definition

    Here an example of maintenance management function of an embedded system



  • Refine interfaces with sequence diagrams

    (Please note the link with the state machine)
  • Here an example of an architecture description of an AUTOSAR software component in SysML
  • The related AUTOSAR configuration generated from the architecture description
  • We do not know about software architecture and decomposition at this stage, but we design main features.

    Please note that “ECU abstraction layer”, “Application voltage state” and “Diagnostic” are standard features for embedded systems.
  • Here an example of software component classification, where the green modules was considered as “non standard” by the management.

    Please always consider two levels of standardisation / reusability:
    1st level for all projects based on the same system, whatever the customer is (so called “STD modules” in the example)
    2nd level for all projects for one customer based on the same system (so called “BMW PDC common modules in the example)
  • Why these two levels ? Improving variant management of embedded systems !

    Here the results for VALEO in a new BMW project concerning the same embedded system as previously.
  • SysML for embedded system engineering - Academy Camp 2015

    1. 1. RÉGIS CASTERAN – SYSTEMS AND SOFTWARE ENGINEERING DOMAIN LEADER 09/23/2015 – V3 Sysml for embedded system engineering
    2. 2. OVERVIEW PART 1 ● Background and challenges PART 2 ● Using SysML at system level PART 3 ● Using SysML at software level PART 4 ● Perspectives 3 13 27 36
    3. 3. PART 1 Background and challenges
    4. 4. 4 Definitions Embedded system BACKGROUND AND CHALLENGES A collection of hardware and/or software elements organized to accomplish a specific function or a set of functions of a larger system. (AGPS, based on INCOSE handbook and ISO/IEC 15288:2015) System engineering An interdisciplinary approach and means to enable the realization of successful systems. (INCOSE handbook)
    5. 5. 5 Definitions Model BACKGROUND AND CHALLENGES A semantically closed abstraction of a system or a complete description of a system from a particular perspective. (ISO/IEC/IEEE 24765:2010) System Modeling Language (SysML) A general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. (Object Management Group)
    6. 6. 6 Background Embedded system breakdown structure BACKGROUND AND CHALLENGES
    7. 7. 7 Background Why and how modeling ? BACKGROUND AND CHALLENGES
    8. 8. 8 Challenges Traceability between managements BACKGROUND AND CHALLENGES
    9. 9. 9 Challenges Traceability between managements BACKGROUND AND CHALLENGES
    10. 10. 10 Challenges Traceability between tools BACKGROUND AND CHALLENGES
    11. 11. 11 Challenges SysML model verification BACKGROUND AND CHALLENGES Criteria Formality level Complexity Review type Instrumentation Understandable Informal Low Walkthrough None Completion Informal to Formal High Model review to Formal testing - Traceability checker - Model transformation to UPPAAL language - Model transformation to B language Robustness Informal High Model review None Consistency Informal to Formal High Model review to Formal testing - OCL checker - Model transformation to UPPAAL language - Model transformation to B language Stability Informal Low Walkthrough None
    12. 12. 12 Challenges SysML model validation BACKGROUND AND CHALLENGES Validation techniques Development state Complexity Instrumentation Simulation At first B-sample release Low Data acquisition (inputs / outputs) Cosimulation At validating first architecture High Model transformation to cosimulation plateform model (Depending on solution capacity to import SysML / UML model) Rapid control prototyping At selecting architecture candidates High - RCP platform - Model transformation to RCP plateform model (Depending on solution capacity to import SysML / UML model)
    13. 13. PART 2 Using SysML at system level
    14. 14. 14 Motivations Stakeholder engagement in requirement management USING SYSML AT SYSTEM LEVEL
    15. 15. 15 Motivations Automisation in architecture management USING SYSML AT SYSTEM LEVEL cmp Network principle NET1_NODE1 NET2_NODE2EQ1 NET1_NODE1 NET2_NODE2 Network_1 + NET1_NODE1 + NET1_NODE2 + NET1_MSG NET1_NODE2 NET2_NODE_1 EQ2 NET1_NODE2 NET2_NODE_1 Network_2 + NET2_NODE1 + NET2_NODE2 + NET2_EQ1_EQ2_VAR + NET2_EQ2_EQ1_VAR NET1_NODE1_PORT1 NET1_NODE2_PORT1 NET2_NODE1_PORT1 NET2_NODE2_PORT1 NET2_EQ1_EQ2_VAR NET2_EQ2_EQ1_VAR NET1_MSG Link Link
    16. 16. 16 Motivations Automisation in architecture management USING SYSML AT SYSTEM LEVEL «XSDcomplexType» nodeType «XSDelement» + address: string + equipment: string [0..1] «XSDattribute» + isLocal: boolean «XSDcomplexType» BaseModel::abstractBaseType «XSDattribute» + isActivated: boolean + name: string «XSDextension» del class PeriodicDataModel «XSDcomplexType» periodicDataType «XSDelement» + arrayNbItems: positiveInteger [0..1] + defaultValue: string [0..1] + offset: nonNegativeInteger [0..1] + type: baseExtendedDataEnumType [0..1] «XSDattribute» + isFunctional: boolean «XSDcomplexType» BaseModel::abstractBaseType «XSDattribute» + isActivated: boolean + name: string string «enumeration» BaseModel:: baseExtendedDataEnumType ANTIVALENT2 AR_CHAR8 AR_INTEGER16 AR_INTEGER32 AR_INTEGER8 AR_REAL32 AR_UNSIGNED16 AR_UNSIGNED32 AR_UNSIGNED8 BCD4 BIPOLAR216 BIPOLAR416 BITSET16 BITSET32 BITSET64 BITSET8 BOOLEAN1 CHARACTER8 ENUM4 ENUM8 INTEGER16 INTEGER32 INTEGER8 REAL32 UNICODE16 UNIPOLAR216 UNSIGNED16 UNSIGNED32 UNSIGNED8 WORD16 WORD8 «XSDextension» Name: Package: Version: Author: PeriodicDataModel «XSDschema» PeriodicDataModel 1.0 ASSYSTEM (RCA) class AperiodicChannelModel «XSDcomplexType» aperiodicChannelType «XSDelement» + arrayNbItems: positiveInteger [0..1] + defaultValue: string [0..1] + type: baseExtendedDataEnumType [0..1] «XSDattribute» + isService: boolean «XSDcomplexType» BaseModel::abstractBaseType «XSDattribute» + isActivated: boolean + name: string string «enumeration» BaseModel:: baseExtendedDataEnumType ANTIVALENT2 AR_CHAR8 AR_INTEGER16 AR_INTEGER32 AR_INTEGER8 AR_REAL32 AR_UNSIGNED16 AR_UNSIGNED32 AR_UNSIGNED8 BCD4 BIPOLAR216 BIPOLAR416 BITSET16 BITSET32 BITSET64 BITSET8 BOOLEAN1 CHARACTER8 ENUM4 ENUM8 INTEGER16 INTEGER32 INTEGER8 REAL32 UNICODE16 UNIPOLAR216 UNSIGNED16 UNSIGNED32 UNSIGNED8 WORD16 WORD8 «XSDextension» Name: Package: Version: Author: AperiodicChannelModel «XSDschema» AperiodicChannelModel 1.0 ASSYSTEM (RCA)
    17. 17. 17 Profiles Principle USING SYSML AT SYSTEM LEVEL
    18. 18. 18 Profiles Rationale USING SYSML AT SYSTEM LEVEL
    19. 19. 19 Profiles Rationale USING SYSML AT SYSTEM LEVEL
    20. 20. 20 Profiles Rationale USING SYSML AT SYSTEM LEVEL
    21. 21. 21 Patterns Example USING SYSML AT SYSTEM LEVEL stm [Package] System state [System state] Powered on INITTESTINGFLASHING FAILEDPower ON SHUTDOWN Final VOLTAGE_MIN_LOW DTC_STORED VOLTAGE_MIN_LOW VOLTAGE_MIN_HIGH stm [StateMachine] Running mode [Running mode] Initial RUNNING Choice MASTER SLAVE Final [(IS_SLAVE_LAST_RUN && ! IS_MASTER_SLAVE_CHANGE_LAST_RUN) || IS_MASTER_LAST_RUN] [Else] stm [StateMachine] Power ON [Power ON] INIT Initial Evaluate requested mode Running mode TESTINGFLASHING Final [MODE == RUNNING] [MODE == FLASHING] [MODE == TESTING]
    22. 22. 22 Requirement management Start with use cases USING SYSML AT SYSTEM LEVEL uc Maintenance Management Embedded system Class:Embedded system «human actor» Maintenance operator Download maintenance data Process maintenance request extension points Maintenance access is granted and maintenance data download is requested Maintenance access is granted and system version identification is requested Maintenance access is granted and new sw version deployment is requested Extension Point : Maintenance access is granted and maintenance data Extension Point : Maintenance access is granted and maintenance data download is requested Determine system status «requirement» SYS_1 notes The system shall set the current maintenance status to "AUTHORIZATION GRANTED" by default. «sw actor» Customer application «extend» «extend»
    23. 23. 23 Requirement management Specify scenarii USING SYSML AT SYSTEM LEVEL sd Process maintenance request from USB key embedded system: Embedded system RUNNING USB key: USB key customer application: Customer application alt USB device test [USB is correctly mounted] alt Maintenance action file test MaintenanceActionFile UsbKeyInserted() updateAuthorization(AUTH_STATUS): boolean readActionFile(): boolean mountUSB(): boolean ReadFile(): boolean
    24. 24. 24 Requirement management Build architecture context with block diagram USING SYSML AT SYSTEM LEVEL bdd [Package] Maintenance Management [Maintenance Management] Ethernet port: Ethernet interface USB port: USB interface LED [3] ASW port: ~Application interface «sys block» Embedded system + mountUSB(): boolean + readActionFile(): boolean + parseActionFile(): boolean + writeMaintenaceData(maintenanceDataType): boolean + updateSystemStatus(systemStatusType) + checkAuthorization(): boolean + updateAuthorization(boolean): boolean properties board : Board bsw : Basic software Ethernet port: Ethernet interface USB port: USB interface LED [3] ASW port: ~Application interface «sys actor» Maintenance PC «human actor» Maintenance operator «sys actor» USB key «hw interface» Ethernet interface isEncapsulated = type = female flow properties in MaintenanceRequest : MaintenanceMessage in swPackage out MaintenanceDataFile : MaintenanceDataFile «hw interface» USB interface isEncapsulated = type = female flow properties in MaintenanceRequest : UsbKeyInserted «signal» UsbKeyInserted Ethernet port: ~Ethernet interface «sys block» Maintenance PC Ethernet port: ~Ethernet interface USB port: ~USB interface «sys block» USB key + ReadFile(): boolean + WriteFile(): boolean USB port: ~USB interface MaintenanceMessage MaintenanceDataFile + type: maintenanceDataType «enumeration» maintenanceDataType «sw actor» Customer application ASW port: Application interface «sw block» Customer application ASW port: Application interface «trace» LedState «flow» «trace» «trace»
    25. 25. 25 Architecture management Split system functions USING SYSML AT SYSTEM LEVEL sd Process maintenance request from USB key embedded system: Embedded system RUNNING USB key: USB key customer application: Customer application /board /bsw alt USB device test [USB is correctly mounted] alt Maintenance action file test [Maintenance action file is correctly formatted] MaintenanceActionFile UsbKeyInserted() writeRAM(AUTH_ADDRESS, AUTH_STATUS): boolean readActionFile(): boolean checkAuthorization(): boolean updateAuthorization(AUTH_STATUS): boolean mountUSB(): boolean ReadFile(): boolean readFile(ACTION_FILENAME): boolean UsbKeyInserted()
    26. 26. 26 Architecture management Split system interfaces USING SYSML AT SYSTEM LEVEL bdd [Package] Maintenance management [Maintenance management] Ethernet port: Ethernet interface LED[3] USB port: USB interface ASW port: ~Application interface «sys block» Maintenance Management::Embedded system + checkAuthorization(): boolean + mountUSB(): boolean + parseActionFile(): boolean + readActionFile(): boolean + updateAuthorization(boolean): boolean + updateSystemStatus(systemStatusType) + writeMaintenaceData(maintenanceDataType): boolean properties board : Board bsw : Basic software Ethernet port: Ethernet interface LED[3] USB port: USB interface ASW port: ~Application interface Ethernet port LED[3] USB port Filesystem: Board filesystem Register: Board register «hw block» Board + readEEPROM(int, int): boolean + readFile(string): boolean + readNVRAM(int, int): boolean + readRAM(int, int): boolean + writeEEPROM(int, int): boolean + writeFile(string): boolean + writeNVRAM(int, int): boolean + writeRAM(int, int): boolean Ethernet port LED[3] USB port Filesystem: Board filesystem Register: Board register «hw interface» Maintenance Management::Ethernet interface flow properties in MaintenanceRequest : MaintenanceMessage in swPackage out MaintenanceDataFile : MaintenanceDataFile «hw interface» Maintenance Management:: LED interface flow properties out LedState : LedState «hw interface» Maintenance Management::USB interface flow properties in MaintenanceRequest : UsbKeyInserted in MaintenanceActionFile : MaintenanceActionFile out MaintenanceDataFile : MaintenanceDataFile ASW port Register: ~Board register Filesystem: ~Board filesystem «sw block» Basic software + checkAuthorization(): boolean + mountUSB(): boolean + parseActionFile(): boolean + readActionFile(): boolean + updateAuthorization(boolean): boolean + updateSystemStatus(systemStatusType) + writeMaintenaceData(maintenanceDataType): boolean ASW port Register: ~Board register Filesystem: ~Board filesystem «sw interface» Maintenance Management::Application interface flow properties out AuthorizationStatus : Boolean «sw interface» Board register flow properties in AuthorizationStatus : Boolean out MaintenanceActionFile : MaintenanceActionFile out MaintenanceRequest : UsbKeyInserted «sw interface» Board filesystem flow properties out MaintenanceDataFile : MaintenanceDataFile +bsw +board
    27. 27. PART 3 Using SysML at software level
    28. 28. 28 Motivations Stakeholder engagement in requirement management USING SYSML AT SOFTWARE LEVEL
    29. 29. 29 Motivations Automisation in architecture management USING SYSML AT SOFTWARE LEVEL ibd [Block] SwcB_JWILL [SwcB_JWILL] RP_IPC_Lat_Acc RP_IPC_Lat_Acc_Valid TMT_RunB_JWILL_4ms TMT_RunB_JWILL_10ms TMT_RunB_JWILL_1ms PP_OPM_Pinion_Torq_Tgt ibd [Block] SwcB_JWILL [SwcB_JWILL] RP_IPC_Lat_Acc RP_IPC_Lat_Acc_Valid TMT_RunB_JWILL_4ms TMT_RunB_JWILL_10ms TMT_RunB_JWILL_1ms PP_OPM_Pinion_Torq_Tgt RP_IPC_Lat_Acc RP_IPC_Lat_Acc_Valid TMT_RunB_JWILL_4ms «Runnable» RunB_JWILL_4ms RP_IPC_Lat_Acc RP_IPC_Lat_Acc_Valid TMT_RunB_JWILL_4ms IRV_TTG_Lat_Acc_weight_X_f IRV_TTG_Lat_Acc_weight IRV_TTG_Lat_Acc_weight_X_k IRV_TTG_Weight_Den TMT_RunB_JWILL_10ms «Runnable» RunB_JWILL_10ms TMT_RunB_JWILL_10ms TMT_RunB_JWILL_1ms PP_OPM_Pinion_Torq_Tgt«Runnable» RunB_JWILL_1ms TMT_RunB_JWILL_1ms PP_OPM_Pinion_Torq_Tgt «delegate» «delegate» «delegate» «delegate» «delegate» «delegate»
    30. 30. 30 Motivations Automisation in architecture management USING SYSML AT SOFTWARE LEVEL
    31. 31. 31 Requirement management Focus use cases on HW interfaces USING SYSML AT SOFTWARE LEVEL uc Software System Overview ECU Abstraction Layer Component:ECUAbstractionLayer «hw actor» PDC ASIC Front: PDC ASIC Front Determine the Park Assistant activation extension points Park Slave PDC Activation Control the Park Assistant PDC Feature extension points before PDC Feature Initialization Manage NVRAM Datas Determine Application Power State extension point: before PDC Feature Initialization «hw actor» Klemme KL15 Coverage: Klemme KL15 coverage extension point: Park Slave PDC Activation «extend» «include» «extend» «include» «include» «include» «include»
    32. 32. 32 Requirement management Describe main features functional flow USING SYSML AT SOFTWARE LEVEL ibd [Block] Software composition [Software composition] ECU GPIO ECU serial port ibd [Block] Software composition [Software composition] ECU GPIO ECU serial port Park state «fct part» PDC activation logic Park state Park state Power state Error state Sensor voltage «fct part» PDC control logic Park state Power state Error state Sensor voltage Power state Battery voltage «fct part» Application power state Power state Battery voltage Error state «fct part» Diagnostic Error state Battery voltage ECU GPIO ECU serial port Sensor voltage «fct part» ECU abstraction layer Battery voltage ECU GPIO ECU serial port Sensor voltage
    33. 33. 33 Architecture management Identify standard components USING SYSML AT SOFTWARE LEVEL «framework» Application - BMW PDC L6 P1::APKM tags isModelDriven = True isStandard = False P1::APKS tags isModelDriven = True isStandard = False «framework» STD Modules P2::Detection System tags isModelDriven = False isStandard = True P2::COMM tags isModelDriven = False isStandard = True P1::VOLT tags isModelDriven = False isStandard = True P2::MXAD tags isModelDriven = False isStandard = True P2::MX12 tags isModelDriven = False isStandard = True P2::PLBMWUPI tags isModelDriven = False isStandard = True «framework» Metrowerks Library + _CHECKSUM_QUAL + _CheckSum1ByteTyp + CHECKSUM + START12 + CHECKSUM_VerifyRO + START12_StartECU (from St «framework» BMW PDC Common Modules P1::AHTST tags isModelDriven = False isStandard = False P1::AMM tags isModelDriven = False isStandard = False P1::AUPA tags isModelDriven = False isStandard = False P1::AKLC tags isModelDriven = False isStandard = False P1::AFESP tags isModelDriven = False isStandard = False P1::ACODI tags isModelDriven = False isStandard = False «BMWtemplatebased» P1::ADIAG «BMWtemplatebased» P1::AMAIN «import» «import» «import»«import»
    34. 34. 34 Architecture management Identify standard components USING SYSML AT SOFTWARE LEVEL «framework» BMW PDC Common Modules APKM tags isModelDriven = True isStandard = False APKS tags isModelDriven = True isStandard = False «framework» STD Modules Detection System tags isModelDriven = False isStandard = True COMM tags isModelDriven = False isStandard = True VOLT tags isModelDriven = False isStandard = True MXAD tags isModelDriven = False isStandard = True MX12 tags isModelDriven = False isStandard = True PLBMWUPI tags isModelDriven = False isStandard = True «framework» Application - BMW PDC L4 AFESP tags isModelDriven = False isStandard = False AHTST tags isModelDriven = False isStandard = False AKLC tags isModelDriven = False isStandard = False AMM tags isModelDriven = False isStandard = False AUPA tags isModelDriven = False isStandard = False ADESC «framework» Metrowerks Library + _CHECKSUM_QUALI + _CheckSum1ByteType + CHECKSUM + START12 + CHECKSUM_VerifyROMChe + START12_StartECU ACODI tags isModelDriven = False isStandard = False EEPIF_SC6: EEPIF EEP_SC6: EEP NVM_SC6: NVM «BMWtemplatebased» AMAIN DEM_SC6: DEM «import»«import» «import» «import»
    35. 35. 35 Architecture management Split main features functional flow between components USING SYSML AT SOFTWARE LEVEL sd Determine Park Assistant State AUPA: AUPA«subsystem» :Diagnostic PDCControlLogic subsystem: PDCControlLogic «subsystem» :ApplicationPowerState «subsystem» PDCActivationLogic: PDCActivationLogic {Application power state has been determined} AUPA_Config / AUPA_Config opt Application power state indicates that the sensor power is supplied [Sensor power supply is ON] UPA_SetRequestedState(u8) XUPA_IS_USENSOR_ON(): bool_T KLC_HSS_GetState(): KLC_HSS_STATE UPA_Cyclic() XUPA_IS_USENSOR_OK(): bool_T PARK_ASSIST_STATE_REQD_IF(u8) HSS_STATE_IF() KLC_HSS_GetState(): KLC_HSS_STATE HSS_STATE_IF()
    36. 36. PART 4 Perspectives
    37. 37. 37 Towards a new AGPS discipline offer: “Model Based Engineering for Embedded System” Principle PERSPECTIVES • Auditing customer both system and software engineering processes • Identifying profiles and patterns opportunities • Building models at system and software level • Specifying, developing and/or sustaining model transformation tools • Specifying, developing and/or sustaining artefact generation tools Next steps • Deploying AGPS profiles and patterns • Writing guidelines for variant management • Writing guidelines for test requirement management • Developing SysML model transformation schemes for verification • … Want to contribute ? • Please send me a mail at rcasteran@assystem.com
    38. 38. Thank you !

    ×