Software Architecture. Definition of Software Architecture. The importance of software architecture. Contents of a good architectural model

Transcription

1 Software Architecture Definition of Software Architecture Software architecture is process of designing g the global organization of a software system, including: Dividing software into subsystems. Deciding how these will interact. Determining their interfaces. The architecture is the core of the design, so all software engineers need to understand it. The architecture will often constrain the overall efficiency, reusability and maintainability of the system. Definition: The software architecture of a program or computing system is the structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and relationships among them. Quality criteria of software architectures: Availability Modifiability Performance Security Testability Usability / Faculteit Wiskunde en Informatica PAGE 0 / Faculteit Wiskunde en Informatica PAGE 1 The importance of software architecture Contents of a good architectural model Why yyou need to develop an architectural model: To enable everyone to better understand the system To allow people to work on individual pieces of the system in isolation To prepare for extension of the system To facilitate reuse and reusability A system s architecture will often be expressed in terms of several different views The logical breakdown into subsystems The interfaces among the subsystems The dynamics of the interaction among components at run time The data that will be shared among the subsystems The components that will exist at run time, and the machines or devices on which they will be located / Faculteit Wiskunde en Informatica PAGE 2 / Faculteit Wiskunde en Informatica PAGE 3

2 Design stable architecture Developing an architectural model To ensure the maintainability and reliability of a system, an architectural model must be designed to be stable. Being stable means that the new features can be easily added with only small changes to the architecture Start by sketching an outline of the architecture Based on the principal requirements and use cases Determine the main components that will be needed Choose among the various architectural t patterns Multi-Layer Client-server e Pipe-and-filter Suggestion: have several different teams independently develop a first draft of the architecture t and merge together the best ideas / Faculteit Wiskunde en Informatica PAGE 4 / Faculteit Wiskunde en Informatica PAGE 5 Developing an architectural model Constraints Refine the architecture Identify the main ways in which the components will interact and the interfaces between them Decide how each piece of data and functionality will be distributed among the various components Determine if you can re-use an existing framework, or if you can build a framework Consider each use case and adjust the architecture to make it realizable Mature the architecture On the technical system architecture: Standards and design patterns Interdependencies among various systems and components Results of feasibility studies Production and service requirements Modifiability and testability requirements Expenditure and risk estimates / Faculteit Wiskunde en Informatica PAGE 6 / Faculteit Wiskunde en Informatica PAGE 7

3 Constraints and conflicts of objectives Specification of Software Architecture Reuse, or building block use, of technical components in various vehicle series Multiple use of engines/transmissions in different series influences architecture of electronics, but one ECU is used with different software version Different vehicle variants within a vehicle series Optional extras vs standard equipment Country specific equipment variants Component-oriented t reuse Based on Analysis of Software Requirements Specification of software components and interfaces Data interfaces Control interfaces Onboard interfaces Offboard interfaces Specification of software layers Specification of operating states normal operation parameterization updating / Faculteit Wiskunde en Informatica PAGE 8 / Faculteit Wiskunde en Informatica PAGE 9 AUTomotive Open System ARchitecture is an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers Objective is to create and establish open standards for automotive Electrics/Electronics architectures that will provide a basic infrastructure to assist with developing vehicular software, user interfaces and management for all application domains A platform for future vehicle applications paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness is a key enabling technology to manage the growing electrics/electronics complexity. aims to be prepared p for the upcoming technologies and to improve cost-efficiency without making any compromise with respect to quality facilitates the exchange and update of software and hardware over the service life of the vehicle / Faculteit Wiskunde en Informatica PAGE 10 / Faculteit Wiskunde en Informatica PAGE 11

4 Why? Increasing complexity of software in automotive systems No standardized software architecture Main motivations Management of E/E complexity associated with growth in functional scope Flexibility for product modification, upgrade and update Scalability of solutions within and across product lines Improved quality and reliability of E/E systems Main goals Fulfillment of future vehicle requirements, such as, availability and safety, SW upgrades/ updates and maintainability Increased scalability and flexibility to integrate and transfer functions Higher penetration of "Commercial off the Shelf" SW and HW components across product lines Improved containment of product and process complexity and risk Cost optimization of scalable systems / Faculteit Wiskunde en Informatica PAGE 12 / Faculteit Wiskunde en Informatica PAGE 13 software components Fundamental design concept is separation between infrastructure and application Application consists of interconnected software components Atomic software component: a software component can not be distributed ib d over several ECUs software component implementation is independent from the infrastructure Communication patterns Client Server Server: provider of service Client: user of service Client initiates communication Single component can be server and client Synchronous and asynchronous communication is possible / Faculteit Wiskunde en Informatica PAGE 14 / Faculteit Wiskunde en Informatica PAGE 15

5 Communication patterns Sender - Receiver Asynchronous distribution of information No response from receivers Sender does not know the number or identity of the receivers / Faculteit Wiskunde en Informatica PAGE 16 / Faculteit Wiskunde en Informatica PAGE 17 Microcontroller Abstraction Layer: lowest software layer of the Basic Software makes higher software independent of Microcontroller ECU Abstraction Layer: Interfaces the drivers of Microcontroller Abstraction Layer Makes higher software layers independent of ECU hardware layout Offers access to I/O Signals / Faculteit Wiskunde en Informatica PAGE 18 / Faculteit Wiskunde en Informatica PAGE 19

6 Service Layer: Highest layer of the Basic Software Offers Memory Services, Diagnostic Services, ECU state management Provides basic services for application and basic software modules Runtime Environment: Middle layer Provides communication services for the application software Makes Software Components independent from the mapping to a specific ECU / Faculteit Wiskunde en Informatica PAGE 20 / Faculteit Wiskunde en Informatica PAGE 21 Software Architecture Application Layer: component style Software components communicate with other components and/or services via the RTE / Faculteit Wiskunde en Informatica PAGE 22 / Faculteit Wiskunde en Informatica PAGE 23

7 Basic Software Services: All system services (e.g. NVRAM, flash and memory management, diagnostic protocols) Communication: communication framework (e.g. CAN, LIN, FlexRay...), the I/O management and the network management. Operating System: standard OSEK OS (ISO ) is used as basis for the OS. The can differ from ECU to ECU but if a proprietary OS is used the interfaces to the Components have to be compliant. Microcontroller Abstraction: All access to the Hardware is routed through the Microcontroller Abstraction layer. This is needed to avoid direct access to microcontroller registers from higher-level software. ECU Abstraction: provides a software interface to the electrical values of any specific ECU to ensure the hardware independence of higher-level software. Complex Device Driver (CDD): provides direct access to hardware for resource critical applications (e.g. injection control, electric valve control). / Faculteit Wiskunde en Informatica PAGE 24