Linked Knowledge Nuggets: arrow_forward "AI in Automotive Systems: Aligning with ISO/PAS 8800"
personAuthor: Sebastian Keller
How can AI be safely integrated into the vehicles of tomorrow?
ISO/PAS 8800:2024 lays the foundation for managing artificial intelligence in safety-related automotive systems. Join our webinar and learn what the new specification means for managers, project leaders, quality specialists, and engineering teams.
We’ll demystify the key concepts behind AI safety, explain how ISO/PAS 8800 relates to ISO 26262, and show how organizations can prepare for the next generation of system validation and assurance.
You will gain an overview of how to transfer AI development activities into structured frameworks such as Automotive SPICE, define roles such as AI safety manager or data governance lead, and avoid common pitfalls such as uncontrolled uncontrolled data drift.
Reserve your spot today and lead your company's AI safety transformation with confidence.
school
Webinar recording and slides
arrow_forward "Testmanagement"
personAuthor: Process Fellows
Test Management ensures that testing activities are strategically planned, monitored, and evaluated across all development phases. From unit tests to system-level integration, this cross-cutting discipline defines methods, tools, documents, and roles to ensure traceable and efficient verification and validation.
school
PF_Testmanagement_Extract.pdf Short Overview of Test Management (related to all Automotive SPICE® verification processes)
# PROCESS PURPOSE
The purpose is to ensure the compliance of the trained ML model and the deployed ML model with the ML requirements.
# PROCESS OUTCOMES
O1
An ML test approach is defined.
O2
An ML test data set is created.
O3
The trained ML model is tested.
O4
The deployed ML model is derived from the trained ML model and tested.
O5
Consistency and bidirectional traceability are established between the ML test approach and the ML requirements, and the ML test data set and the ML data requirements; and bidirectional traceability is established between the ML test approach and the ML test results.
O6
Results of the ML model testing are summarized and communicated with the deployed ML model to all affected parties.
# BASE PRACTICES
BP1
Specify an ML test approach. (
O1 )
Specify an ML test approach suitable to provide evidence for compliance of the trained ML model and the deployed ML model with the ML requirements. The ML test approach includes
ML test scenarios with distribution of data characteristics (e.g., gender, weather conditions, street conditions within the ODD) defined by ML requirements,
the distribution and frequency of each ML test scenario inside the ML test data set,
the expected test result per test datum,
the pass/fail criteria of the testing,
the entry and exit criteria of the testing,
the approach for data set creation and modification, and
the required testing infrastructure and environment setup.
Note 1: An expected test result per test datum might require the labeling of test data to support the comparison of the output of the ML model with the expected output. Note 2: Test datum is the smallest amount of ML data which is processed by the ML model into only one output. E.g., one image in photo processing or an audio sequence in voice recognition. Note 3: Data characteristic is one property of the ML data that may have different expressions in the ODD. E.g., weather condition may contain expressions like sunny, foggy or rainy. Note 4: An ML test scenario is a combination of expressions of all defined data characteristics, e.g., weather conditions = sunny, street conditions = gravel road.
BP2
Create the ML test data set. (
O2 )
Create the ML test data set needed for testing of the trained ML model and testing of the deployed ML model from the ML data collection provided by SUP.11 considering the ML test approach. The ML test data set shall not be used for training. Note 5: The ML test data set for the trained ML model might differ from the test data set of the deployed ML model. Note 6: Additional data sets might be used for special purposes like assurance of safety, fairness, robustness.
Linked Knowledge Nuggets: arrow_forward "What's the difference between "corner cases" and "unexpected cases"?"
personAuthor: Process Fellows
Corner cases are extreme or rare scenarios that lie within the expected value range.
They occur rarely, but are still part of the domain.
Examples:
An image recognition model for cats recognizes a cat with a very unusual coat color (e.g. completely pink).
An autonomous vehicle encounters an unusual traffic route, but this is provided for in the road traffic regulations (e.g. an extremely tight hairpin bend).
A very high or very low value in a time series data set (e.g. a share price rises by 100% in a single day).
Corner cases often require fine-tuning or special training data to ensure that the model works reliably even in these rare cases.
Unexpected cases are scenarios that the model did not anticipate because they are outside the training domain or are not covered by the data model.
Examples:
An image recognition model for cats is supposed to recognize a cat, but the image contains a new animal species that the model has never seen (e.g. a Sphynx cat if the model only knows furry cats).
An autonomous vehicle encounters a completely new traffic regulation or an unexpected road situation that it has never seen before in training data (e.g. a sudden earthquake and collapsing bridges).
A language model is confronted with a new language or dialect that it does not know.
Unexpected cases often cannot be solved simply by using more training data.
This is where approaches such as out-of-distribution (OOD) detection, anomaly detection or unsupervised learning help to react to completely new cases.
arrow_forward "Which test data sets to be used for ML testing?"
personAuthor: Process Fellows
The ML test data set is used for the final testing of the trained ML model and the deployed ML model. The ML test data set must not be used for training! This means that no significant changes/optimizations may be made based on the ML test data set. This is because with every optimization, information about the data set quickly finds its way into the model, leading to overfitting to the data set used.
If the test fails and optimization of the ML model is required, it must be ensured that the ML test data set remains reliable in order to guarantee compliance with ML requirements. Therefore, a change to the ML test data set may be necessary.
Regression tests:
Aim: to ensure that the deployed model (i.e. transferred to the target hardware) delivers the same results as the original model (on the training platform).
Causes for deviations: numerical differences caused by hardware-specific implementations (e.g. floating-point arithmetic, quantization).
How is it done?
Same test data set is used for testing the trained model and the deployed model.
Outputs are compared: if there are deviations, they are analyzed to see if they are within an acceptable tolerance.
Example: If the prediction error < 1%, the deployed model is considered as “stable” (i.e., acceptance criteria to be defined as part of MLE.1!)
Remark: In safety-critical applications (e.g. autonomous driving, medical technology), even small differences may be unacceptable.
Additional test data:
The neural network is now running in a real environment, HW-specific aspects need to be tested, e.g.
Performance tests: speed, memory consumption, latency times
Robustness tests: behavior in case of heat, voltage fluctuations, memory errors
Edge cases / malfunctions: e.g. how does the model behave with incorrect or noisy inputs on the target hardware?
How is it done?
Test data sets can be extended by:
Inputs with higher noise or extreme values
Live data from the target hardware (e.g. sensor data instead of static test images)
Performance tests under load
BP3
Test the trained ML model. (
O3 )
Test the trained ML model according to the ML test approach using the created ML test data set. Record and evaluate the ML test results. Note 7: Evaluation of test logs might include pattern analysis of failed test data to support, e.g., trustworthiness.
BP4
Derive the deployed ML model. (
O4 )
Derive the deployed ML model from the trained ML model according to the ML architecture. The deployed ML model shall be used for testing and delivery to software integration. Note 8: The deployed ML model will be integrated into the target (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) and may differ from the trained ML model which often requires powerful (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and uses interpretative languages.
BP5
Test the deployed ML model. (
O4 )
Test the deployed ML model according to the ML test approach using the created ML test data set. Record and evaluate the ML test results.
BP6
Ensure consistency and establish bidirectional traceability. (
O5 )
Ensure consistency and establish bidirectional traceability between the ML test approach and the ML requirements, and the ML test data set and the ML data requirements; and bidirectional traceability is established between the ML test approach and the ML test results. Note 9: Bidirectional traceability supports consistency, and facilitates impact analyses of change requests, and verification coverage demonstration. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP7
Summarize and communicate the results. (
O6 )
Summarize the ML test results of the ML model. Inform all affected parties about the agreed results and the deployed ML model.
# OUTPUT INFORMATION ITEMS
13-52
Communication evidence (
O6 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Process performance management process attribute
13-51
Consistency evidence (
O5 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
11-50
Deployed ML model (
O4 )
Deployed ML modelIdentifies:
The source code derived from the trained ML model that shall be executed in the target (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).
Examples and references:
It may differ from the trained ML model which often requires powerful (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and uses interpretative languages.
The deployed ML model is usually written in programming languages like C/C++.
Used by these processes:
MLE.4 Machine Learning Model Testing
03-51
ML data set (
O2 )
Selection of data for machine learning training and validation, or test of a machine learning model.Identifies:
Patterns
Relationships
Features
Includes:
Annotations and labels
ML Training and Validation Data Set
ML Test Data Set
Used by these processes:
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
08-64
ML test approach (
O1 )
Approach describing criteria and activities to test ML models.Identifies:
ML test scenarios
Distribution of data characteristics, for example gender of persons or weather conditions
Related ML requirements
Pass/fail criteria
Entry and exit criteria
Environment setup and configuration
Includes:
References, for example with test data set
Used by these processes:
MLE.4 Machine Learning Model Testing
13-50
ML test results (
O3, O4 )
Results of ML test activitiesIdentifies:
Test data and logs
Test data with correct results
Test data with incorrect results
Test data not executed, and a rationale
Includes:
Information about the test execution (date, participants, model version etc.)
MLE.4
Machine Learning Model Testing
