Launching a good ECU product is the first step to success. But to really take off, a product platform needs to be created. This step enables a targeted investment in a base product that can then be implemented at reduced cost and with lower risks in projects for various customers.
Whether a re-usable platform element approach is planned at the start of development does not play a role. This may only emerge in the course of the pilot project or during further discussions with customers. The crucial point is that the realizable synergy effects are greater the earlier a decision in favor of a re-use approach is made.
A modern ECU software architecture skillfully combines COTS products such as a classic AUTOSAR stack, product-specific drivers and applications, and integration components of other development partners. The better the re-usable components are separated, the easier they will be to use in subsequent projects.
Efficiently implementing subsequent customer projects by using such a kit becomes effortless. The benefits accrue throughout the entire A-SPICE cycle. From requirements management to testing, customer projects profit from the work that was already done.
The classic AUTOSAR standard provides a suitable basis for projects and platforms. The interfaces, limits of abstraction, and configuration options defined in the standard are particularly well suited for designing re-usable applications. Defined exchange formats and models help with the design of automated tool chains and workflows.
The question of re-usability gets interesting when it comes to basic software. Tailor-made modules can be integrated into AUTOSAR-compatible basic software systems using complex drivers. This allows the generic basic software to be expanded with specific functions when needed.
The classic AUTOSAR standard provides helpful complex driver resources such as interface agreements, compatibility rules, and model-based configuration concepts. Using this foundation efficiently for one’s own platform concepts does however require high-performance tool support.
As long as discrete software modules are used exclusively within one project, their individual design is only important in this limited context. File and code structures, configuration rules, and documentation follow the project rules in this case. With comprehensive platform concepts however, the goal must be to implement each element of the kit to be as self-contained as possible, with a formal structure according to a recurring pattern. Benefits include simplified integration in projects and good maintainability in the course of the project.
Synergy effects are not limited to the mere re-use of previously created modules. Maintenance during the project term is also highly efficient with the help of a suitable QM concept. Relevant information about the re-use packages from the projects is supplied to platform development. This may include malfunctions, integration problems, incomplete documentation, or functional enhancements. The resulting updates or upgrades of the re-use packages can then be transferred to the relevant projects quickly and easily, without the burden of long integration cycles or manual carry-overs.
The KYOTO approach supports users in the creation of re-usable packages. Such packages are called “GUnits” (generator units) in this context. A GUnit encompasses all components that are necessary for its use in projects:
Today’s software developers expect a suitable development environment that includes intelligent editors, debuggers, and automation tools. This facilitates development and keeps productivity and motivation high. KYOTO therefore provides a comprehensive development environment for GUnits with the Designer. It provides high-performance editors for all file formats, comprehensive documentation, and complete debugging functions for all active components of a GUnit.
Users of the GUnits should be able to use them in projects without difficulty. Quality is therefore essential. Since the packages are re-used in multiple projects, the resulting leverage also means that the quality of user projects can be positively or negatively influenced to a great extent. This makes the quality of the GUnits crucial. Thus the KYOTO Designer provides test environments for all active components of the GUnits. Templates, validation rules, and also algorithms can be verified through the structured creation of test scenarios and test cases. Standardized test reports are quick and easy to integrate into subsequent processes and KPI dashboards.
A package alone does not make a kit. It is created by making a collection of packages available together. The KYOTO Designer’s release cycle allows collections of the developed packages to be made available in any combination as an update site (see the container in Figure 4). These containers are the platform’s delivery artifact and the interface to the user.
The containers are delivered via central artifact management platforms. Here the complete container is available in a standardized form, visible for all projects. A straightforward, direct, and reproducible rollout is assured. All delivered versions are available in the artifact repositories, so that regressive access to older versions is always given.
The developers and integrators in the customer project deal with the transfer of different deliveries to the project context. Accordingly, the KYOTO Configurator provides an efficient tool with a clear layout to integrate elements of the kit into the project quickly and easily. The desired containers are transferred directly from the artifact repository to the configurator environment using the update mechanism.
Configuration of the prepared GUnits
Now the user can focus on using the prepared elements of the kit according to the purpose. Here the KYOTO Configurator provides support with the stored parameter definition, easy to use editors, and processing tools. Live validation based on the validation rules stored in the GUnit is available, providing the user with direct feedback during configuration. A comment function is provided to record useful information directly on the configuration parameters. This not only facilitates analysis and review, but can be used as an added level for change tracking as well.
Two additional package types are available aside from the GUnits that can be generated.
Framework processes often provide information pertaining to the configuration of certain GUnits. A meaningful way to transfer information of any kind to configuration data is needed here.
That is where IUnits come in. They contain tailor-made import logic that can be perfectly adapted to the preliminary products during development in the Designer. Like other platform elements, these IUnits are packaged in the kit container. This makes them readily and quickly available to integrators in projects. The import logic is developed once in the KYOTO Designer and then re-used in all matching projects. Here the format of the available advance information plays a minor role – all common formats are supported.
A tool rarely stands on its own! Integrating KYOTO into tool chains is therefore essential for ease of use during integration. EUnits make it possible to create tailor-made external tool links. They support the control of other tools and integration of the data flow (input and output data) with the KYOTO Configurator workspace. External generators, analysis tools, and reporting tools can be easily integrated.
Many generator-based approaches quickly lose their advantages in the context of safety-related projects. When trust in the generator is lacking, the correctness of generated artifacts has to be checked manually. This takes considerably more effort and valuable time. A qualification kit is therefore available for the KYOTO generator, providing automated qualification according to ISO26262 for applications up to ASIL-D as needed.