Software Architectural Design

Transcription

1 Software Architectural Design

2 6-5 Initiation of product development at software level ISO Product development at Software level 6-6 Specification of software safety requirements 6-7 Software architectural design Software testing 6-10 Software integration and testing 6-8 Software unit design and implementation Software testing 6-9 Software unit testing 2

3 Overview ISO requirements for Architectural Design A suitable architectural notation - AUTOSAR Design architecture for testability Demo with dspace SystemDesk

4 What are ISO requirements for Software Architectural? ISO Suitable notations From System architecture down to Software units description Representation of static and dynamic aspects Enabling of reusability for subsequent activities (Design, Testing, Integration) Managing complexity : modularity, encapsulation, maintainability Safety mechanisms Freedom of Interferences within Software partitioning Errors detection and handling Verification of architectural design Compliance with safety requirements Fit for integration purpose (Software and Hardware) 4

5 Architectural notations Drawing, Excel + Might be suitable for small application - Error-prone - Difficult to verify and maintain - Not suitable to describe dynamic aspects Microsoft Word, Excel, Visio yed graphical editor - Difficult to reuse for subsequent activities such as design, test, integration - Not standardized, no standard guidelines for freehand drawing 5

6 Architectural notations Simulink + Standardized syntax, model-oriented, executable + Syntax allows static verification + Suitable to describe dynamic aspects Mathworks Simulink + Reusable for subsequent activities such as design, test, integration - No full semantic of implementation level 6

7 Architectural notations AUTOSAR (AUTomotive Open System Architecture) + Standardized notation + Syntax and Semantic are available Syntax: AUTOSAR Metamodel + ARXML files Semantic: RTE-Communication throughout standardized interfaces AUTOSAR allows description from System down to Software Units and ECUs configuration Best candidate to comply with ISO Architectural Design requirements 7

8 ISO compliant architectural notation AUTOSAR 8

9 AUTOSAR Motivation and Goals Key concept = Standardization of the Software Architecture of ECUs Non-AUTOSAR Software Hardware Standardized interfaces Hardware specific AUTOSAR Application Software AUTOSAR Basic Software Hardware Manage complexity Modular development where software and hardware are independent Reusable software components Exchangeability thanks to standardized interfaces Improve reliability and performance System architecture becomes manageable Early detection of architectural errors Easier collaboration thanks to standardized formats (OEMs/Suppliers share the structure of the global system) Reduction of development costs, Increase of quality 9

10 AUTOSAR Motivation and Goals Modularity in AUTOSAR allows to: Create a modular architecture based on Atomic Software Components Design Software Architecture and Functions without hardware specification Adapt ECU architecture : Split architecture into different ECUs Transfer of SWCs between ECUS, Cores Modify channel of data acquisition Change communication network MPC 5554 NEC V850 NEC V850 Core 4 Core 5 Core 1 Core 2 Core 3 CAN DIO FlexRay PWM 10

11 AUTOSAR ECU architectural Example of Power Window Validate driver AUTOSAR Interface Validate passenger AUTOSAR Interface Control AUTOSAR Interface Driver switch AUTOSAR Interface Passenger switch Passenger Window ADC PWM CAN driver Movement request Movement command Obstacle detection 11

12 AUTOSAR Elements and Terminology Interface int16 speed; int8 temperature; Atomic Software Component Software SWC1 SWC2 Architecture out Port in AUTOSAR Composition RTE Event SWC1 Runnable Runnable 3 Internal Behavior Runnable 1 Data Access Interrunnable Variable Runnable 2 out

13 AUTOSAR - Modeling with dspace SystemDesk SystemDesk Exported ARXML 13

14 DEMO 14

15 AUTOSAR ISO Compliant SW architectural description Architectural Notation Architectural Safety mechanisms Architectural Verification NOTE: The software architectural design is not necessarily limited to one microcontroller or ECU, and is related to the technical safety concept and system design. The software architecture for each microcontroller is also addressed by this chapter The software architectural design shall be developed down to the level where all software units are identified. Internal Behavior 15

16 AUTOSAR ISO Compliant SW architectural description Architectural Notation Architectural Safety mechanisms Architectural Verification Reusability: Standardized Interfaces and exchange formats Verifiability : Validation against AUTOSAR schema Modularity: Hardware-Software independent Encapsulation: Layered architecture Static aspects: Compositions, SWCs, Interfaces, Ports, Runnables Dynamic aspects: OS, Tasks, RTE Events Methods ASIL A ASIL B ASIL C ASIL D AUTOSAR 1a Hierarchical structure of software components 1b Restricted size of software components System, ECUs, Layers, Compositions, SWCs, Runnables c Restricted size of interfaces d High cohesion within each software component 1e Restricted coupling between software components f Appropriate scheduling properties g Restricted use of interrupts Table 3 - Principles for software architectural design Increased number of SWCs can rely on AUTOSAR interfaces for proper integration Sender/Receiver and Client/Server Interfaces offer flexibility in defining communication between SWCs AUTOSAR Internal Behavior is a perfect description of the SWC cohesion SWCs can be decoupled individually or grouped as Composition to minimize changing impacts RTE Events offer variable solution of scheduling Runnables (DRE, TEV, OIE, MSE, ) RTE Events offer variable solutions for asynchronous execution of Runnables 16

17 AUTOSAR ISO Compliant SW architectural description Architectural Notation Architectural Safety mechanisms Architectural Verification ISO requests the detection and handling of safety issues like : hardware faults at runtime data corruption and wrong service calls requirements on timing and logical order of execution of applications communication protection of applications Methods ASIL A ASIL B ASIL C ASIL D 1a Range checks of input and output data b Plausibility check c Detection of data errors d External monitoring facility o e Control flow monitoring o f Diverse software design o o + ++ Table 4 - Mechanisms for error detection at the software architectural level Methods ASIL A ASIL B ASIL C ASIL D 1a Static recovery mechanism b Graceful degradation c Independent parallel redundancy o o d Correcting codes for data Table 5 Mechanisms for error handling at the software architectural level 17

18 AUTOSAR ISO Compliant SW architectural description Architectural Notation Architectural Safety mechanisms Architectural Verification 18 AUTOSAR supports Safety by offering standard safety mechanisms 1. Memory partitioning: separate software applications from each other in order to avoid any data corruption between applications 2. Defensive behavior: prevent data corruption and wrong service calls in the AUTOSAR basic software on microcontrollers having no hardware support for memory partitioning. 3. End-to-end communication protection: protect applications against the effects of faults within the communication link 4. Program flow monitoring: control the temporal and logical behavior of applications 5. Time determinism and timing constraints modeling: allow modeling and implementing proper and deterministic timing behavior of applications and basic software 6. Hardware testing and checking: AUTOSAR basic software modules to test hardware (e.g. RAM-Test, Core-Test) and to check the integrity of stored data (e.g. EPROM Manager)

19 Example - E2E communication Input: Bus-Structure containing Data-Elements for checksum (CRC) and sequence counter (SQC) Special E2E Comspec Block has second output for status 19

20 Example - RTE-Status 20

21 Example - Signal invalidation as output 21

22 AUTOSAR ISO Compliant SW architectural description Architectural Notation Architectural Safety mechanisms Architectural Verification AUTOSAR architecture can be verified with authoring tool like SystemDesk Methods ASIL A ASIL B ASIL C ASIL D AUTOSAR with SystemDesk 1a Walk-through of the design ++ + o o None 1b Inspection of the design c Simulation of dynamic parts of the design SystemDesk model-based architectural design improve readability and statical analysis SystemDesk allow dynamical simulation of AUTOSAR composition 1d Prototype generation o o + ++ Generation of AUTOSAR virtual ECUs 1e Formal verification o o + + Formal verification based AUTOSAR Schema, Compilation 1f Control flow analysis Manual inspection 1g Data flow analysis Missing connections are detected 22

23 Design Software architecture for Testability 23

24 Design Architecture for testability Design Architecture for testability Hierarchical approach Reduce complexity Ease unit tests Calibratable software Reusable functions Design and test algorithm once, and reuse Well placed internal signal for debugging Restricted coupling between Runnables and between SWCs Minimize loop-dependencies Ease data flow analysis SWC1/R1 SWC2/R1 ServerCall ServerCall Runnable server 24

25 Testing AUTOSAR with dspace and BTC SystemDesk TargetLink BTC Tools TL AUTOSAR model Arxml files AUTOSAR-compliant C code Containers RTE Frame BTC Tools support testing of AUTOSAR communication SWC UNDER TEST Inputs Outputs DRA Runnable calprm pim DWA Runnable Ports access points DataReceivePoint CalprmAccessPoint ShareCalprmAccessPoint Ports access points DataSendPoint RPort Runnable (Server) argout argin retval Runnable (Client) Operation (ServerCallPoint) argout argin retval PPort Runnale (Server) Operation call ReceiverComSpec.RTEStatus SenderComSpec.FeedBack Internal beh. access points IrvReadAccess PIMCalprmVariableAccess SharedCalprmAccess Operation ArgIN Operation ArgIN SenderComSpec.Invalidate Internal beh. access points IrvWriteAccess PIMVariableAccess Operation ArgOUT OperationReturnValue Operation ArgOUT OperationReturnValue 25

26 Testing AUTOSAR with dspace and BTC SystemDesk TargetLink BTC EmbeddedTester 26