The automotive powertrain has become steadily more complex over the past decades. Demanding emission and CO2 legislation calls for more advanced control strategies while new safety and comfort functions are causing a higher nesting of functionalities. Additionally, an increasing number of product variants must be considered. As a result, software is becoming a core innovation and cost factor.
As a countermeasure to combat this complexity, FEV has developed a new software development process. This process and the accompanying tool chain is called PERSIST (Powertrain control architecture Enabling Reusable Software development for Intelligent System Tailoring). It can be applied at an early stage of function development.
The solution involves simplification of the number of calibration parameters and interfaces by applying model-based control and implementation of the functions within a software architecture that reflects the control strategy, allowing for standardization and leveraging of the reuse potential. This joint strategy reduces development time and cost by speeding-up software specification and implementation through reuse and reduced calibration effort.
Development framework and software architecture
The framework requirements can be summarized into three aspects:
- Design for software quality
- Application from early prototyping phase to volume production
- Continuous quality assessment
Diverse investigations, conducted by FEV, show that architecture has a severe influence on software quality. Early design decisions can either guarantee code which satisfies various needs or complicates later working steps including implementation, integration and testing significantly. Shorter development cycles urge software developers to react quickly to changes or updates of requirement definitions. As a consequence, quality must be checked continuously using agile development principles. Late detection of quality defects (e.g. shortly before development milestones) are avoided since the verification and validation status is continuously updated.
Fig. 1 shows the resulting development approach that incorporates these requirements. It is based on the daily performance of automated implementation, verification and validation and release activities for a defined software function library that follows a consistent architecture. Changing requirements can be taken into account quickly and new release candidates can be generated that are available for field validation. Suitable agile methods and long-term architecture development are combined and form the basis for efficient application of automated development support.
Parallelized development of control units
The reference architecture is AUTOSAR. The System Architecture is derived from system requirements by grouping functionalities (logical architecture) and defining use cases and customer acceptance tests. Functionalities are assigned to mechanical and electronic system components (technical architecture). Once this step is complete, the development of different control units can be parallelized to decrease the development time.
Software Architecture development involves Software Component (SW-C) definition and the assignment of System Requirements to them. To profit from automated accessibility of all functions Continuous Integration (CI) is also used for automated quality assessment in addition to performing code generation, build and, for example, documentation tasks.
The CI principles are adapted in accordance with the development framework requirements: All developers contribute work products on a common data repository. An integration server polls the work products regularly and performs a build while also processing the software model verification and validation (V&V). This includes diverse aspects of quality checks such as modeling guidelines, metrics or unit tests.
Model-based control for simplified calibration Over the last ten years FEV has developed model based control concepts for both air and fuel path control for demonstrator and series usage. The main targets of these developments were to enable strongly reduced calibration effort especially reducing the effort for ambient corrections, which are in most cases compensated
by the physical based structures. At the same time these physical based functions also lead to significant increase of overall system robustness and to redundancies in certain information (such as certain temperatures and pressures, but also emissions like NOx) which can then be used for increased emission robustness, model adjustment or reduction of sensor content. All these control concepts are transferred into the PERSIST framework for easy reuse and better
As one example Fig. 2 shows the architecture of the emission based air path control concept for Diesel engines. This concept controls the EGR path(s) based on a target engine-out NOx emission level.