10 Jahre Modellierung bei Continental, eine ehrliche Bilanz

Transcription

1 Bitte decken Sie die schraffierte Fläche mit einem Bild ab. Please cover the shaded area with a picture. (24,4 x 11,0 cm) Entwicklungsprozesse mit der UML für eingebettete Systeme 10 Jahre Modellierung bei Continental, eine ehrliche Bilanz Commercial Vehicles & Aftermarket

2 Continental Corporation Five Strong Divisions Chassis & Safety Powertrain Interior Tires ContiTech Vehicle Dynamics Engine Systems Instrumentation & Driver HMI PLT, Original Equipment Air Spring Systems Hydraulic Brake Systems Transmission Infotainment & Connectivity PLT, Repl. Business, EMEA Benecke-Kaliko Group Passive Safety & Sensorics Hybrid Electric Vehicle Intelligent Transportation Systems PLT, Repl. Business, The Americas Compounding Technology Advanced Driver Assistance Systems (ADAS) Sensors & Actuators Fuel & Exhaust Management Body & Security Commercial Vehicles & Aftermarket PLT, Repl. Business, Asia Pacific Commercial Vehicle Tires Conveyor Belt Group Elastomer Coatings Two Wheel Tires Industrial Fluid Systems Mobile Fluid Systems Power Transmission Group PLT Passenger and Light Truck Tires Vibration Control 2

3 Business Unit Commercial Vehicles & Aftermarket Segments and their Portfolio Tachographs, Telematics & Services Vehicle Electronics* Independent Aftermarket Original Equipment Services Digital tachograph solutions Instrument clusters OE & platform solutions ATE wear and tear parts for brakes All original parts of Automotive Group Analogue tachograph solutions Accessories & services for workshops Fleet management Telematic products Single gauges Body controller for trucks Driver working place Body builder module VDO replacement parts (fuel systems, actuators for central locking systems, engine actuators, HVAC blower & fan systems, screen & headlight washer systems, sensors, tire pressure monitoring systems) Portfolio for service & replacement to OEMs (commercial & passenger vehicles) Off & On-Highway transmission ECU Chassis master control unit Light control module Platform multiplex solutions Multi-brand diagnostics OE diagnostics & services Diesel repair service Brake service equipment & tools *Selective products from product categories 3

4 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 4

5 Motivation Target Achievement Abstract and understand complex Systems Formal Development Approach How do we come to a solution (break down) Why have we chosen this solution (rationale) Where are requirements implemented (traceability) Effective and reliable Verification and Validation Consistency between Architecture, Documentation, Code, Test, 5

6 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 6

7 The Project DTCO1381R2 Tachograph for European market Common Criteria Security Evaluation (highest Attack level) Major Project Goal: Cost reduction (using new Security-Architecture) Project Domain Team: Multi-site / Multi-team Approach: Migration based on existing software, by isolating security related features into additional microcontroller (called SecCon ) Restricted HW: CPU: 32 bit, 33 MHz Code/Data: 380 Kbyte (usable) RAM:10 Kbyte (usable) 7

8 Architectural Principles Definition of a Static Structure Central Entry Point (Architectural Views) Clear Hierarchy for SW Modules (Layers) Clear Structure within the Modules (Interface, Implementation) Definition of a Workflow Abstraction Methodology Definition of Abstraction Level 0 3 Level 0: Cross System Level (Collaboration) Level 1: System Level (Device) Level 2: Sub-system Level (Controller SW Architecture) Level 3: Component Level (SW Module SW Design) 8

9 System Overview (level 1) 9

10 Process V-Model Feature Driven Development (FDD) Project Management Horizontal Traceability (Validate/Verify) Stakeholder Requirements Acceptance Test Vertical Traceability (satisfy) Requirements Engineering n Performance Specification Architecture & Design Software Architecture & Design Software Detailed Design n+2 Integration Test Integrations test plan / specification Software Test System Test System test plan / specification n+1 Software Specification & Design Software test plan / specification Implementation Configuration & Change Management Requirements Management 10

11 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 11

12 Structure Overview (level 1 & level 2) The Architecture consists of several Layers 2. The Architecture Additional Packages provides Architectural Rules Use Case Folders provide high level Abstraction Different Views on the Model provides a good Overview 12

13 Structure Overview (level 1 & level 2) The Use Case folders are container for corresponding Feature Sets 3. The Analysis The Feature Sets are satisfying Requirements Sequence Diagrams are showing Scenarios of the Feature Sets on different levels and impact The Overview consists of all identified Feature Set represented as UML Use Cases 13

14 Structure Architecture & Design SW Architecture (Level 2 Diagram) SW Design (Level 3 Diagram) 14

15 Structure Views (level 2) 4. The Service View The Service View shows an Overview of all existing Services It defines Types which represents the Message structure and the Service IDs 5. The Module View The Module View shows all existing Modules and how they collaborate 15

16 Structure Module Interface Overview SW Architecture Layer model (level 2) 16

17 Structure Implementation / Test (level 3) Each Module is stored in its own CI 10. The Module Structure The Test Package is stored in a separate CI Requirements are satisfied on Module level Each Module can have more detailed Level3 Sequence Diagrams 17

18 Structure Implementation / Test (level 3) The Test Package contains Unit and Module Tests 11. The Module Test The Module Tests are again stored in a separate CI The Component consists of several Configurations The Tests are created according the defined Feature Sets 18

19 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 19

20 The Project DTCO3283R1 New Module Development NCMDT is a new Module Uses object oriented C Provides Singleton Objects for accessing the Services Provides callback Interfaces to be implemented by the clients Documents its behavior with several SDs Uses Code Generation for Statecharts 20

21 ServiceCoordinator State Behavior /switchoffncmpowersupply(me); me->fatalerrorcounter = 0; Only powered in system states: GLOB_nwMfm, GLOB_nwSfpm, GLOB_nwNom, GLOB_nwOv m, AdrMode setncmstatus(me, encmdtncmmodulestatus_notready);... Idle setncmstatus(me, encmdtncmmodulestatus_notread... eventeradrmode [else] evexitadrmode evsystemmodechange[ [isswitchonrequired(me, params->currentmode) == true] isswitchonrequired(me, params->newmode) == true] Startup-Timers: ReadyTimer: 15sec (inccnt=0.5sec) evsystemmodechange[ StatusRequestTimer: 0.5sec isswitchoffrequired(me, params->newmode) == true] eventeradrmode Powered resetalltimers(me); me->commandretrycount = 0; NcmDtCommandDispatcher_notifyStartUpPhase(me->itsDispatcher, true); TurnOff Power TurnsOn power Reset NCM ResetNcm managestartsequence(me); evresetdone/ resetncmreadytimer(me); enablestartupcontroller(me); [me->rescnt > NcmDtResCntMax]/ setncmstatus(me, encmdtncmmodulestatus_defectncm); WaitUntilNcmModuleReady Halt Note: Setting of the encmdtncmmodulestatu s_notready depends on the exit condition of the Powered state. If there was no explicit reason(for Ex. Fatal errors) to leave the Powered state then it is set. If there was a explicit reason (for Ex. Communication error) then it is not set. [else] [isncmreadytimerexpired(me) == true] The lifecycle status should be one of the literals defined in NcmDtLifecycleSt atus evstatusrequesttimerexpired GetNcmStatus DelayStatusRequest (void)ncmdtservicecoordinator... reloadncmstatusrequesttimer(me); incrementncmread... evncmstatusreceived [else] [isncmready(me, params->equipmentstatus) == true]/ resetalltimers(me); The fatalerrorcount er is needed to identify communicaton errors in ADR mode as the Halt state can be manipulated [else]/ setncmstatus(me, encmdtncmmodulestatus_lifecycleerror); evprocessevent LifeCycleIsWrong A [NcmDtLifeCycleMonitor_setLifecycleStatus(me->itsLifeCycleMonitor, Complex Statechart params->lifecyclestatus) == true] [else]/ me->fatalerrorcounter++; setncmstatus(me, encmdtncmmodulestatus_notready); [else] [NcmDtLifeCycleMonitor_isNcmBlocked(me->itsLifeCycleMonitor) == true]/ setncmstatus(me, encmdtncmmodulestatus_blocked); evfatalncmerror CheckSwVersionAndNcmCrypto me->iscmdrequested = false; [iscmdretrialneeded(me, params->rescode) == true] [NcmDtFatalErrSupressCnt <= me->fatalerrorcounter]/ setncmstatus(me, encmdtncmmodulestatus_communicationerror); evsoftwareversionreceived [else]/ SwVersionIsWrong setncmstatus(me, evprocessevent encmdtncmmodulestatus_wrongsoftwareversio n); [else] ev LifecycleErr/ [issoftwareversioncorrect(me, params->version) == true]/ setncmstatus(me, me->commandretrycount = 0; encmdtncmmodulestatus_lifecycleerror ); [iscompletestartupallowed(me) == false] [else] [isncmequipmentok(me, params->rescode, encmdtcommandidentifier_getncmactivatio ndata) == false] NCM-command Response-TimeOut If NCM-module does not respond within t= 5 sec to a command-request it will lead to a fatal error (service abortion). Complete list of Fatal error cases at: RussiaUseCasesAndServices.xls (Tab Errs, Filter _ErrServiceAborted) me->iscmdrequested = false; me->iscmdrequested = false; CheckNcmCryptoAndGnss CheckNcmDatabase Operating [else] [else]/me->commandretrycount = 0; evresponsecodereceived enableservices(me); me->fatalerrorcounter = 0; NcmDtCommandDispatcher_notifyStar... evresponsecodereceived [iscmdretrialneeded(me, params->rescode) == true] [iscmdretrialneeded(me, params->rescode) == true] [else] evstartncmreset/setncmstatus(me, encmdtncmmodulestatus_notready);me->freezerescnt = true; Reset requested by the client. At the moment Card Client [else]/ updategnssstatus(me, params->rescode); [isncmequipmentok(me, params->rescode, encmdtcommandidentifier_exch angemotiondata) == false] [isncmequipmentok(me, params->rescode, encmdtcommandidentifier_recordfaultoccu red) == false] ErrorOccured [isgnssdefect(me) == true]/ setncmstatus(me, encmdtncmmodulestatus_defectgnss); [else]/ setncmstatus(me, encmdtncmmodulestatus_defectncm); Lifecycle management:... If one of the conditions below is met, the reset of the NCM will enforce the correct setting of the lifecycle during startup. 1. Detection of lifecyle-state "Blocked": After the NCM entered Blocked, it will reply with error WrongCommand to the first command sent that is not allowed. As part of the startup, the lifecycle-state is read and updated. 2. Generally as the life cycle progresses the service availability and commands availibility grows, in any case if there is a intermediate Lifecycle where a service or a command have to be disabled will also lead to a reset as command will not be accepted by NCM. 21

22 The Project DTCO1381Rx The Release View provides information for several releases Within a Release is Information about all the changes Each Feature has its own Package FeatureSet Modules show the related Module changes They inherit from the real Modules and show the needed changes and responsibilities The Features have also SDs and Requirement traceability 22

23 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 23

24 System: Cash Machine Card Reader Touch Panel Key Pad 24

25 System: Cash Machine Use Cases Analysis (level 0) act [Activity View] GetMoneyBlackBoxView [Architecture] insertcard cardinserted enterpin pinentered authenticate Pin [authenticated] readcardid readpinnum ber askforamou nt [else] notifycustom er askforpin verifypin tobecontinu ed [verified] [else] 26

26 System: Cash Machine Scenario: Use Case Execution I (level 0) sd [Package] GetMoneyBBScenariosPkg [AuthenticationFailed] :Customer :Uc_GetMoney evinsertcard() cardinserted() cardid=readcardid() askforpin() eventerpin() pinentered() cardpin=readpinnumber() verifypin(pin:cardpin) authenticatepin(pin:cardpin) notifycustomer() 27

27 System: Cash Machine Use Cases Partitioning (level 0) act [Activ ity View ] GetMoney WhiteB oxv iew [D esign] «B lock» CashMachine «Block» Authenticator «B lock» CardReader «B lock» KeyP ad «B lock» TouchPanel Customer insertcard cardinserted readcardid askforpin pinentered Customer enterpin verify Pin readpinnumb er [v erified] authenticatep in [else] notify Custom er [else] [authenticated] tobecontinue d askforamou nt 28

28 System: Cash Machine Scenario: Use Case Execution II (Happy Day level 0) sd [Package] CashMachine_WB_SD_Uc1 [HappyDay] The Lead Architect defines the Specification :Customer :CashMachine :CardReader :TouchPanel insertcard() reqcardinserted() cardinserted() reqreadcardid() cardid=readcardid() :KeyPad :Authenticator reqaskforpin() All parties are involved enterpin() askforpin() reqpinentered() pinentered() Result of an Iterative Analysis and Design Process reqreadpinnumber() cardpin=readpinnumber() reqverifypin() verifypin(pin:cardpin) reqauthenticatepin() authenticatepin(pin:card askforamount() reqaskforamount() tobecontinued() reqtobecontinued() 29

29 System: Cash Machine Static software architecture (level 2) ModuleOverview ENG.5.BP1 Architecture «Interface» CardListener «Interface» KeyPadListene «Interface» TouchPanelList «Requirement» Requirements.i ID = 10 ENG.5.BP1 Component «satisfy» CashMachine 1 Authenticator «satisfy» «Requirement» Requirements.i ID = 7 ENG.5.BP2 Allocate Req. ENG.5.BP10 Traceability Design 1 CardReader 1 KeyPad 1 TouchPanel «satisfy» «Requirement» Requirements.i ID = 8 ENG.5.BP9 Traceability Architecture «satisfy» «satisfy» «satisfy» «satisfy» «Requirement» Requirements.i «Requirement» Requirements.i «Requirement» Requirements.i «Requirement» Requirements.i ID = 4 ID = 6 ID = 5 ID = 9 30

30 System: Cash Machine (Not shown in talk) Software construction (level 3) ENG.5.BP6 Detailed Design AuthenticatorOverview 1 PinRequester Authenticator authenticatepin(... comparepins(st... «satisfy» «Requirement» Requirements::id11 ID = 11 The Authentication must not take longer than 30 ms. 1 HashCalculator 31

31 System: Cash Machine Dynamic software architecture (level 2) ModuleBehavior_HappyDay_mod :Customer :CashMachin e :Authenticator :CardReader :KeyPad :TouchPanel ENG.5.BP3 Interfaces 1. Insert the card insertcard() cardinserted() If a card is inserted, it is read to identify the customer. ENG.5.BP4 Behavior readcardid() askforpin() cardid() To authenticate the customer, a pin is requested. ENG.7.BP3 Test Spec 2. Enter the pin enterpin() ENG.5.BP7 Verification Criteria readpinnumber() pinnumber() pinentered() If a pin is entered, it is read to authenticate the customer. ENG.5.BP8 Verify Design UC Step verifypin() authenticatepin(cardid, pinnumber) authenticated() {4 digit} askforamount() The stored and hashed pin on the card is authenticated against the entered pin. If the customer is authenticated, it is asked for the amount of money. 3. Request the money --> to be continued... 32

32 System: Cash Machine (Not shown in talk) Software construction (level 3) ENG.5.BP6 Detailed Design AuthenticatorOverview PinRequester 1 Authenticator ENG.6.BP9 Traceability SW Unit authenticatepin(... comparepins(st... ENG.6.BP5 Verification Criteria ENG.6.BP10 Traceability Test Spec «satisfy» «Requirement» Requirements::id11 ID = 11 The Authentication must not take longer than 30 ms. 1 HashCalculator ENG.6.BP4 Develop 33

33 System: Cash Machine (Not shown in talk) Software construction (level 3) sd [module] Authenticator [Authenticator_HappyDay] ENG.6.BP2 Analyze SW Units ENV :Authenticator :PinRequester :HashCalculat or :CardReader ENG.6.BP8 Traceability SW Unit ENG.6.BP3 Prioritize authenticatepin(cardid, pinnumber) getpin(cardid) requestpin(cardid) ENG.6.BP5 Verification Criteria storedpinhash() calculatehash(pinnumber) enteredpinhash() hashedpin() ENG.6.BP6 Verify authenticated() comparepins(storedpinhash, enteredpinhash) Requirements::id7 ENG.7.BP7 Traceability Arch./Design ENG.7.BP4 Integrate SW The stored and hashed pin on the card is authenticated against the entered pin. 34

34 Agenda Motivation Introduction Tachograph Project Structure Tachograph Legacy Development Future Development Support and Barriers 35

35 Summary Full Bilateral Traceability Full Consistency Improves Communication Validity of Documentation Reuse of Documentation Lots of Powerful Diagrams Performed in real Projects with Assessments 36

36 Summary Guided and Formal development process Reducing Errors Simpler Tracing Growing Design Single Source Common data storage Less redundancies Reliable, Consistent and Traceable More re-use Automation Executable Models 37

37 Support and Barriers Support for lots of Standards Process Models (CMMI, (Automotive)SPICE, ) Quality Charachteristics (ISO9126, ISO25010, ) Safety Standards (ISO26262, ISO61508, ) Barriers Management needs to understand the need of this technology Management needs to support it (Time, Budget, Commitment) Employees need to be qualified Employees need to get the chance to collect experience Projects need to have support from Experts (Coaching) 38

38 Thank you for your attention! 39