Continuous Integration of service applications

Transcription

1 Continuous Integration of service applications Automotive Diagnostic Systems 2013 Dr.-Ing. Markus A. Stulle IFS IFS Informationstechnik GmbH Trausnitzstraße München Sitz: München Registergericht: Amtsgericht München HRB Geschäftsführer: Dr.-Ing. Markus A. Stulle Dipl.-Ing. Thomas Frey

2 Company and self-conception Founded in 1999, 50 employees Portfolio: automotive engineering, cybernetics, development tools, process tools. Since 2011 member of ASAM e.v. Supplier of the BMW Group since 2000 The best way to predict the future is to invent it. (A. Kay) Current priority: mobile applications based on Microsoft Windows Phone Mobile first!. Page 2 s

3 Continuous Integration of service applications What is software quality? From discrete integration to Continuous Integration (CI) Process tool Prometheus Test framework Anubis of Serviceplattform Taurus Vehicle emulator Virgo A best practice based on automated system tests Page 3

4 What is software quality? - indirect definition required Cross-disciplinary definition of errors by Martin Weingardt: In the face of an alternative, a subject understands the variant as error which - in terms the correlating context and a specific interest is regarded as so disadvantageous that it appears to be undesirable. Software quality Use cases are fulfilled without errors Application gives a positive user experience Efficiency in operation and maintenance. Page 4

5 What is software quality? - corollary Implementation free of errors not sufficient to achieve high software quality! Timely provision of proofs of concept as primary objective ( speed is the essence! ) Metrics for source code Suitable for an one time only accuracy check, e.g. for the evaluation of offshore providers Unsuited for continuous quality management, since the likelihood of errors doesn t correlate with the metrics. Page 5

6 Error-free authoring of source code - collaboration Pair programming - two persons work together on the same function in one session at one computer Higher likelihood that technical and functional errors are recognized thanks to mutual monitoring Can make component test dispensable! Disadvantages: personnel placement is at least doubled, asymmetrical cooperation, little acceptance among employees! Groupware solution Collabode (MIT CSAIL) makes it possible to work on the same source code module at separate computers. Page 6

7 Error-free authoring of source code - component tests Testing of the implementation of a software component F with a defined function call f(x) Test scenarios T: Function arguments x have to cover the co-domain as completely as possible Development of mock-ups laborious, comparison between the expected and the actual results of the functions requires the knowledge and abilities of the developer of F According to the best practice the development of the component and the test is carried out in disjunctive groups Contradicts the demand for a short cycle time! Page 7

8 Causes of software errors - lack of knowledge Errors occur, because some use cases haven t been identified yet the paradigm or the technology is new some facilities of the platform are unknown the documentation is insufficient. because there is a lack of knowledge and of time to acquire this knowledge! Page 8

9 Software for service applications - axioms Crisis of acceleration All software projects suffer from Missed deadlines Pressure to be innovative: Mobile gadgets set the pace! Nobody makes mistakes due to want of care! All speak the same language Example Taurus spoken here Page 9

10 Strategies for high software quality - process models Software engineering, here: V-model Basic approach: Once everything has been written down, we know everything! Page 10

11 Process models - V-model (I) Objective to meet requirements precisely Procedure listing of all requirements, modeling of use cases, systematic elaboration of concepts Characteristics Division into specification stage and implementation stage Sequential development: concept - specification - implementation - integration - testing Page 11

12 Process models - V-model (II) Disadvantages Strictly sequential: Defects, flaws, technological obstacles won t be detected until implementation or testing In the time between proof of concept and system integration, the platform has often been developed further Merging of development outputs takes place at a singularity ( big bang integration ) Page 12

13 Process models - Simultaneous Engineering (I) Objective early detection of flaws in the specification Procedure parallel stages Characteristics Early implementation of development outputs Mutual exchange between the stages concept / specification implementation / integration system testing Page 13

14 Process models - Simultaneous Engineering (II) Discrete Integration successive merging of development outputs integration planning integration candidate 1 integration candidate 2 integration candidate n release candidate system test time integration production review Page 14

15 Discrete Integration - revision control trunk branches bugfixes branches functional enhancements implementing requirements and committing integration production system test Page 15

16 Discrete Integration - disadvantages Implementation adheres strictly to the integration planning, little scope for individual initiative It s difficult to determine the causes of errors via system testing, since integration merges many different branches Quantity structure of a service application software repair 394 software modules over 2 million lines of source code 265 test cases of system tests, 6477 test cases of regression tests in 40 test plans Software components typically violate the principle of weak causality. Page 16

17 Continuous Integration - concept Objective to identify the origins of errors! Procedure abandon the use of development branches, timely integration of changes on all trunks Characteristics before each commit: production, installation and system testing At all times a state in which of products are error-free and ready to be deployed J. Humble, D. Farley Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Page 17

18 Continuous Integration - requirements and components Definition of an integration product Process tools for FMEA data base and risk assessment Automated production Production of software components is replicable thanks to assembly according to bill of materials Automated distribution and installation on target platform ( delivery ) Automated selection, execution and interpretation of system tests in target environment Page 18

19 Continuous Integration - evolutionary steps Introduce an issue for error correction or functional enhancement Changes of source code strictly adhere to the issue Production of the correlative packages Process tool calculates system tests based on the FMEA data base of the changed source code modules Mounting of test constructions within the test framework, performance and evaluation of relevant system tests Commit of the changed modules or escalation according to the process Page 19

20 Process tool Prometheus - FMEA data base Page 20

21 Process tool Prometheus - selection of system tests Page 21

22 Process tool Prometheus - definition of use case Use case requires a basic function Functions are effected by source code modules Modules are items of the bills of material Page 22

23 Process tool Prometheus - Risk assessment of a project Radar charts facilitate the comparison of risks Execution duration of the system tests due to be executed is known Question Can the functional enhancement be released in the maintenance window? can be answered easily! Page 23

24 Service application - roles of the operator Role R 1 functioning as an actuator Control variables of the application are communicated via the user interface, e.g. in form of a text display Turn the steering wheel to straight-ahead position! Role R 2 functioning as a sensor The discrete measurands determined by the operator are also communicated via the user interface, e.g. by pressing a button. Role R 3 functioning as a selector Selection among alternatively executable sub-functions of the service application Page 24

25 Control system of service application, vehicle, VCI and operator Challenge: Roles R 1, R 2 and R 3 of the operator are carried out on the human machine interface Page 25

26 Control system of service application, test framework Anubis and replicas Roles R 1 and R 2 from the operator model, Role R 3 substituted by suitable ISOM/L programs Page 26

27 Test framework Anubis - implement system test case (I) Implement system test: substitute Role R 3 in ISOM/L Prepare tracing of operating record Page 27

28 Test framework Anubis - implement system test case (II) Implement system test: assume Roles R 1,2 Operating records link situations and user input in the FMEA data base Reproduction by Anubis in the automated system test Page 28

29 Replicas for system tests - vehicle emulator Virgo Discrete event dynamic system (DEDS) models for control units taken from a clean room approach Petri net as the form of modeling permits concurrency Emulation also replicates the electrical system of the vehicle and the sensors Hybrid emulation: Integration of CAN bus hardware allows gradual transfer to real vehicle Replica of vehicle communication interface, e.g. SAE J2534. Emulation description can be generated by Taurus during a vehicle session (and transferred to cloud service) Page 29

30 Vehicle emulator Virgo - example plug-in hybrid Durango 18 control units, diagnostic protocol UDS Vehicle access via eplanet, LTE and K-Line (ISO 9141) Service application based on ASAM/MCD Challenge: software updates anywhere! Page 30

31 Virgo-GUI - start of emulation (I) Virgo-GUI uses Virgo as well as Anubis via web service interface Interactive preparation of test scenarios Page 31

32 Virgo-GUI - presentation of Virgo vehicle access Page 32

33 Virgo-GUI - modeling of traction battery Page 33

34 Vehicle emulator Virgo - enhancement Reality Engine CVDS models for components, e.g. seat heating DEDS models for driver, e.g. temperature perception Parameters and events can be controlled by the test framework Page 34

35 Vehicle emulator Virgo - petri net of control unit INSTRUMENTS Concurrency: firing of T 6 puts tokens on E 1 and F 3 Behavior of transitions can be controlled via web service at runtime Even complex service situations can be constructed by test framework Anubis Page 35

36 Vehicle emulator Virgo - control unit memory model (I) Service situations: control unit memory model allows replication of defective memory cells Page 36

37 Vehicle emulator Virgo - control unit memory model (II) Software logistics: Virgo can associate memory contents with applications Seite 37

38 Vehicle emulator Virgo - control unit memory model(iii) System dynamics: time behavior of model is configurable Page 38

39 Process tool Prometheus - select system tests (I) test cases use cases test coverage Page 39

40 Process tool Prometheus - select system tests (II) FMEA data base provides prognosis for overall duration of the system test cases Page 40

41 Process tool Prometheus - select system tests(iii) Presentation of reduced test coverage in tree map Page 41

42 Process tool Prometheus - execute system tests Parallel execution in test case groups with up to 5 vehicles Emulations are individualized by Anubis, e.g. by setting a VIN Values of performance criteria are automatically computed and compared to former system tests Page 42

43 Continuous Integration - best practice At the very beginning: define an integration product, automate production, distribution and installation Build a FMEA data base, link use cases and system tests Provide replicas for operator and vehicle Implement system tests Develop functional enhancements within issues The commit of source code changes triggers assigned system test cases. Page 43

44 Michael Nagy, Presseamt München We are looking forward to seeing you at our exhibition stand! Tel.: kontinuierliche-integration.de, continuous-integration.org Document: BZ Page 44