Lesson 14 of 16 · The V, process by process · Automotive SPICE, the vital 20 %
The V at system level: SYS.1 to SYS.5
Lesson 4 drew the V as a chain of traces. This lesson opens each system-level box: what it asks for, what an assessor expects to find, and the few rules that decide its rating.
In the recommended VDA Scope, SYS.1 Requirements Elicitation is…
Can a model in a design tool, with no document titled "System Architecture", satisfy SYS.3?
Seat-Heat's company bids for the whole ECU
So far Seat-Heat has written software for hardware supplied to it, so its assessment covered the software plug-in only. For the next vehicle generation, its company bids to deliver the complete seat-heating ECU: microcontroller, power stage for the heater mat, temperature sensor input, LIN interface, housing, and Seat-Heat's software inside. A system team now owns the ECU as a whole, and the system processes come into scope.
"System" in ASPICE is not a fixed product level. The SYS processes are "not tied to a particular system boundary": a mechatronic-system or drive supplier can apply them to its mechatronic system, an ECU supplier to its ECU, a chip supplier to its microcontroller[Guidelines §2.3.2, pp. 47–48]. Whatever the team delivers as its product is its system.
The left leg: from needs to an architecture
| Process | What it asks for | What an assessor expects to find |
|---|---|---|
| SYS.1 Requirements Elicitation | Obtain stakeholders' expectations, agree them as requirements, analyse every change to them, and keep their status visible to all affected parties. | Stakeholder requirements with their source, evidence of agreement, change analysis. Outputs include 17-00 Requirement and 15-51 Analysis results. |
| SYS.2 System Requirements Analysis | Specify functional and non-functional system requirements with defined characteristics (such as verifiability), structure and prioritise them, analyse correctness and feasibility, analyse their impact on the system context, trace them to the stakeholder requirements, and communicate them. | A structured requirement set, analysis results, consistency evidence to the stakeholder requirements. |
| SYS.3 System Architectural Design | Specify the static aspects (system elements, interfaces, relationships) and the dynamic aspects (behaviour and interaction in each system mode), analyse the design, record the rationale for key decisions, derive special characteristics for the non-software elements, trace, and communicate. | 04-06 System architecture, analysis results, 17-57 Special characteristics. |
Source: PAM §4.3.1–4.3.3, pp. 33–38.
Two words in that table are wider than they sound. A stakeholder requirement is not only the customer's: the PAM's examples also include the supplier's own (product-specific or platform), legal, regulatory and statutory requirements, industry-sector requirements, international standards and codes of practice, and the list is open. A system element can be logical, a structural object at architecture or design level that may be decomposed further, or physical, or a combination, such as a sensor, an actuator, a mechanical part or a software executable[PAM p. 10].
Three things from the Guidelines that decide ratings here:
- Structure means more than two folders. If "functional" and "non-functional" are the only way the requirements are structured, then SYS.2.BP2 "shall be rated as N" (SYS.2.RL.5)[Guidelines p. 122]. Group by function, feature or variant instead. SWE.1.RL.4 says the same for software requirements.
- Requirements may grow by release. When not all system requirements exist yet because of release-driven incremental development, BP1 and BP2 are not downrated (SYS.2.RL.4)[p. 121].
- The architecture needs both views. At least one static and at least one dynamic view; no particular set of views is prescribed[p. 125]. The hardware-software interface is defined at system level, in SYS.3, and is an input to the software requirements[PAM SWE.2.BP1 note 1, p. 46].
Not every customer requirement travels down the V. Only requirements about the product itself need to trace down to design and verification. Process requirements (such as "reach ASPICE level 2") and work-product requirements (such as a coding standard) are evidenced in other ways, for example by audit reports[Guidelines §3.3.1, pp. 116–117].
The right leg: one pattern, used five times
SYS.4 verifies the integrated system against the architecture: interfaces, signal flow and timing between elements, hardware–software interaction. SYS.5 verifies the integrated system against the system requirements, including aspects such as thermal behaviour, robustness and EMC[PAM §4.3.4–4.3.5, pp. 39–43]. Both are written to broadly the same pattern, and so are SWE.4, SWE.5, SWE.6 and, for validation, VAL.1. Learn it once, and expect small variations (SWE.5, for instance, splits component verification from integration verification):
- Specify the verification measures. At system level that means techniques, pass/fail criteria, entry and exit criteria, sequence, and the infrastructure and environment setup; the list is shorter for some processes (SWE.4 names pass/fail and entry/exit criteria and infrastructure).
- Select which measures to run, with criteria that include regression, documented, with "sufficient coverage according to the release scope".
- Perform them and record the results, with pass/fail status. Deviations go to SUP.9.
- Trace the measures to what they verify (bidirectionally, and consistent), and the results to the measures.
- Summarise and communicate the results to all affected parties.
ASPICE 4 says "verification" rather than "testing" on purpose: "testing is not the only verification approach". Measurements, calculations, analyses and simulations are verification measures too[Guidelines §2.3.6, p. 61].
| Rule | What it says |
|---|---|
| SYS.4.RL.2, SYS.5.RL.2 | An automated verification measure whose definition doesn't address the correctness, completeness and consistency of its scripts and programs: BP1 shall be downrated. |
| SYS.4.RL.3, SYS.5.RL.3 | Exploratory tests can't trace to the architecture or the requirements, and BP4 is not downrated for that. Each exploratory test must still trace to its results. |
| SYS.4.RL.4, SYS.5.RL.4 | A sound selection of measures, made against an inadequate or incomplete release plan: BP2 is not downrated. The weakness belongs to the release planning. |
Source: Guidelines §3.6–3.7, pp. 128–132.
Test code is a work product too. A hardware-in-the-loop (HIL) suite that runs every night proves nothing if nobody has asked whether its scripts check the right thing. The Guidelines make that part of defining the measure, and downrate its absence.
Practice
A. Which system process?
The OEM's 200-page specification is read, clarified in two workshops, and agreed as the requirement set for the first release.
"The ECU shall regulate the heater-mat temperature measured at its sensor input to the selected setpoint within ±2 °C, at ambient temperatures from −20 °C to 60 °C", derived from a line of the OEM specification and linked to it.
A block diagram of microcontroller, power stage, sensor input and LIN transceiver, plus a sequence diagram of what happens at start-up.
On a test bench, the power stage and the flashed microcontroller are brought together step by step, checking the PWM signal timing across the interface.
In a climate chamber, the complete ECU, driving a reference heater mat, is checked against its temperature-regulation requirement at −20 °C.
B. Would an assessor downrate?
The system requirements are sorted into two folders, "Functional" and "Non-functional", and nothing else.
Release 3's system requirements are not written yet; releases 1 and 2 are complete, and the release plan shows when release 3's will be.
The HIL tests run automatically every night. Their definitions say nothing about how the test scripts themselves are checked.
The EMC requirements are verified by measurement in an EMC lab, specified as a measurement procedure with pass/fail limits and traced to the requirements, with no test cases in the test tool.
Exploratory sessions on the test bench trace to no requirement, but each session is recorded and linked to its findings.
C. From memory
Name the five steps the verification processes on the right of the V broadly share.
Specify the verification measures (techniques, pass/fail, entry/exit criteria, sequence, infrastructure); select them, with regression criteria and sufficient coverage for the release scope; perform them and record the results; trace measures to what they verify and results to measures; summarise and communicate the results.
What does SYS.1 deal with that SYS.2 doesn't?
The stakeholders' own expectations: obtaining them, agreeing them as stakeholder requirements, and analysing their changes. SYS.2 turns the agreed stakeholder requirements into structured, analysed system requirements for the product and traces back to them.
Your win: you can say what each system-level process asks for, tell SYS.4 from SYS.5, and name the pattern every verification process follows. Next: the same walk through the software level, where most of a software team's evidence lives.
To keep it: import this lesson's Anki deck (how).
Read next
The SYS processes in the PAM, pp. 33–43, then their chapters in the Guidelines §3.3–3.7, pp. 114–132. The Guidelines' Table 3-1 on which requirements trace down is worth the detour.
Does your team deliver software, an ECU, or something bigger? Ask your teacher in the chat where your system boundary sits.