The Story of ASPICE-Lite

Background

As an engineer, I have always been interested in the patterns in life and how things are often equivalent. As a student, I would try to 'wind up' my mechanical engineering tutors by solving mass-spring-damper problems using their electrical circuit equivalent. For the electrical engineering tutors, I would do the opposite and solve their problems using the mechanical systems analogy. For me, they were just dynamic systems represented by differential equations, but in different domains; the rules that were applied in one domain could (and should) apply in different domains when viewed from the right perspective.

This perspective is central to the philosophy of ASPICE-Lite by AJB in that the same 'rules' should be (and are) used in different domains such as systems, software, electrical, mechanical, hydraulic etc. For example, a systems architecture, a software architecture and an electronics architecture should all use the same 'rules', albeit with some minor tailoring for each domain.

My primary objective in developing ASPICE-Lite by AJB was to make it (and ASPICE generally) more accessible to all people and something that real engineers completely understand, approve and sign on to. Adopting these principles enables people to make their lives simpler and their daily tasks more enjoyable, by enabling them to focus on engineering.

I should start by stating that :

I am in no way associated with Automotive SPICE
I think that the general content of the ASPICE processes are good and well intentioned

Having said that, I think that some of the processes in ASPICE can be simplified by taking advantage of similarities between different engineering domains and generalizing the processes, rather than adding new processes that are largely similar to existing ones for each new domain.

Rationalization of ASPICE 3.1

The first step in development of ASPICE-Lite by AJB was rationalization of several core processes that were almost identical between the systems and software domains. In reality, you could do a 'search and replace' of 'systems' with 'software' to get 90% of the way there. The remaining differences were minor and could be accommodated by generalizing the wording whilst maintaining the key concepts. This was done for the following pairs of processes:

SYS.2/SWE.1 - Systems/Software Requirements Analysis
SYS.3/SWE.2 - Systems/Software Architectural Design
SYS.4/SWE.5 - Systems/Software Integration/Integration Test
SYS.5/SWE.6 - Systems/Software Qualification Test

This step is in-line with the DRY principle and reduces the number of processes by 4 with no reduction in the quality of work products that are produced - note: this is a process simplification and does not reduce the resources needed to produce the work products.

In the second step, a missing stage in the architectural design process was added that was required for SYS.4/SWE.5 (system/software integration & integration test) to completely make sense in my mind; this step was the definition of a subset of architectural elements (and associated test setup) that would be required during system/software integration and integration test. For example. a Hardware-in-the-Loop test system (with real-time plant models) may be required for system integration testing, a Model-in-the-Loop test setup (with plant model) may be required as part of software integration and stubs/dummy modules may be required for software integration. All these items should be considered at the architectural design phase to allow time for selection, design, procurement, configuration and/or implementation to take place. This has been included in the process step "Define architectural variants for integration and integration test" with the added benefit of forcing the development team to consider these items earlier rather than just before needed for integration testing (when it is probably be too late).

The third step was the realization that an improvement to the generic system/software architectural design process that replaced SYS.3/SWE.2 could make the natural cascade of requirements to the next level much simpler by just applying a filter to the requirements database to 'extract' the requirements that apply to a specific architectural element; this would make SWE.1 an almost trivial exercise and led naturally into step 4 of the process improvement.

In step 4, the 'trivial' nature of SWE.1 was completely eliminated by adapting the new architectural design process to include a step to "order, categorize and prioritize" new requirements that were created from the decomposition of requirements according to the architecture. This also meant that this process could then become recursive in that an architectural element could then be treated as an 'item' for further decomposition and that the requirements for any architectural element could simply be obtained by applying a filter the the requirements when extracting them from (or viewing them in) the requirements database. A natural corollary from this is that SYS.4/SWE.5 (systems/software integration and integration test) also became recursive processes.

ASPICE 4 Updates

With the advent of ASPICE 4, the impetus to continue to evolve ASPICE-Lite by AJB continued. Specifically, issues were:

The omission of a separate hardware architectural design process that parallels the software process
Hardware/software integration & integration test process
The addition of a new set of processes for machine learning that could (and should) have simply been incorporated in the software processes

Hardware architectural design

In many real world projects, there is clearly a need for separate hardware architectural design process step (and not just bury this step as a Base Practise as in HWE.2.BP1). For example, an inverter control system for an electrical machine will typically have a microcontroller board (MCB) and a separate power electronics (PEB) board (often tightly coupled and mounted together). This would require only one diagram to elaborate the architecture, but the design, functions, requirements and interfaces for these 2 boards are quite distinct.

My view is that the same fundamental process of decomposition of requirements and allocation to architectural elements can be equally applied at the system, software and hardware levels, and that taking this approach greatly simplifies the "plug-in" concept to other domains such as mechanical, hydraulic, thermal, etc. I have therefore included this in the base Architectural Design process.

Hardware/Software Integration and Integration Test

An even more important distinction occurs when considering integration of hardware with associated base (or platform) software (BSW). A very literal (but incorrect) interpretation of ASPICE would have separate and completely independent hardware and software design streams that only interact when at the system integration level via the hardware/software interface (HSI). The reality is somewhat more complex, but does not present a challenge if handled using ASPICE-Lite by AJB.

Considering the inverter control unit in the above example, I regard the electronics hardware and base software as tightly coupled development items, and only loosely coupled to the application software (ASW) due to the way in which they should be integrated. An example (and purely theoretical) integration test plan would be :

Step 1a : Integrate and test ASW + RTE/Model I/F + Model using a MiL environment
Step 1b : Integrate and test BWS + RTE + Dummy ASW + MCB using an IO Tester
- The dummy ASW is required to stimulate outputs and measure/log inputs
- The HiL (in step 2) could be used as an IO tester
Step 2 : Integrate BSW + MCB + ASW in HiL environment
- MiL model transfers to HiL
- A test Board may be needed to replace the PEB and provide interface between the PEB and HiL
Step 3 : Add the PEB and perform system level testing on HiL with dummy loads (non-rotating)
Step 4 : Integrated testing at a system level on an electrical machine test rig

Note: The above assumes that bring-up testing of electronics has already been completed as well as BSW/ASW unit testing and some BSW integration testing (method TBD).

This has been covered in terms of planning in the new architectural design process and, in terms execution, in the new Integration and Integration Test process

Machine Learning

Does machine learning need a separate set of processes? The basic answer, in my opinion, is "No"; they can be covered by the normal software development processes and therefore are superfluous. There are however some important considerations that are covered in the machine learning (or related support) processes that are relevant to data and hyper-parameter management and that should be incorporated into the SW general processes.

Consider an electrical machine controller based on a torque / efficiency model of the electrical machine. This model may be generated automatically by fitting the model to experimental data with some "hyper-parameters" (to use the machine learning lingo) that configure the model fitting process such as smoothing, breakpoint locations in lookup tables, etc. This would traditionally be referred to as "calibration" even though there is no manual adjustment of any parameters. Analogous situations have been happening over many years with internal combustion engine models for air flow, friction, torque, throttle body and volumetric efficiency models and, more recently for battery cell models in EVs. These were just not called machine learning and instead referred to as "model parameterization" but the general principals still apply; it should be possible to re-create any work product at any point in time using data and/or (hyper-)parameters stored in the project repository (i.e. under version control/configuration management).

For this reason, I have added a process under the grouping 'Information Management' to cover this need and have made no changes to the base software processes.

New Processes

Up until now, I have been focusing on the removal and streamlining of processes, but there are some processes that are required that are either missing in ASPICE 3.1 and 4, or are hidden/obscured in support processes. These processes are :

System definition
System release
System maintenance

System Definition

System definition is a simple process, but one that seems to be missing in ASPICE 3.1/4 and should be performed before requirements elicitation to make sure that all the stakeholders have a common understanding of the system boundary, its interaction with its operating environment, what is inside and outside the system boundary and the context in which the system operates.

I would expect that the system definition typically takes place during the project preparation/planning phase and may form part of an project business case, RFQ and/or supplier proposal (otherwise how do all the stakeholders know what is meant by the "system"?). However, it is important that this information is captured as it may then be used in many different work products (see 'Documentation Guidelines' on recommendations as to how to do this whilst keeping to the DRY principle).

In terms of functional safety, this also covers 'item definition' as defined in ISO26262.

System Release

This is covered in ASPICE under SPL.2 but has been moved as a core process in ASPICE-Lite by AJB due to its importance. Note - the same process may be applied to many items such as systems, software, electronics, etc. The process details the type of information that is required and that should be applied to all release notes, regardless of whether they are hardware, software and/or systems.

System Maintenance

This is partly covered in SUP.10 (Change Request Management), but has been added to ASPICE-Lite by AJB to highlight that System Maintenance in the form of change requests may be an on-going activity that occurs after System Release, and not just during development. Note: This refers to maintenance of work products such as requirements, designs, implementations, testing/test results and documentation, and does not refer to service and maintenance of physical end products (i.e. vehicles).