Sample project battery management system

All examples and images in this help come from one consistent sample project: the battery management system (BMS) of the high-voltage battery of an electric vehicle in the 400 V and 800 V variants. The project was chosen because it shows the typical process at automotive suppliers: a vehicle manufacturer delivers a requirements specification, the supplier derives safety goals and system requirements from it and verifies them with test cases.

The content of the sample project is in German; the user interface in the images follows the selected language.

Try it yourself

Under Projects → New project → Demo project you load the data set into one of your groups. You get configuration, modules, artifacts, links and the baselines v1.0 and v1.1 with the suspect links. Review, change request and comments belong to the fictitious people of the sample company and are only shown in the images of this help; create them yourself for practice.

Content

Module	Content
Stakeholder-Anforderungen (stakeholder requirements)	Requirements specification of the vehicle manufacturer with 20 requirements (functions, safety, environment, interfaces)
Sicherheitsziele (safety goals)	4 safety goals from the hazard analysis and risk assessment according to ISO 26262 with ASIL
Systemanforderungen (system requirements)	40 system requirements and 3 constraints, structured by measurement, state estimation, charging, cell balancing, protection functions, communication and diagnostics, operation and environment
Verifikation (verification)	30 test cases (test bench, hardware-in-the-loop, vehicle) with test result
Glossar (glossary)	10 technical terms such as state of charge (SoC), main contactor, thermal runaway

The configuration extends the ISO/IEC/IEEE 29148 profile with the type safety goal and attributes such as ASIL, variant, limit value and unit. This shows how a project can be adapted to your own standards and terms (Project properties).

What you will find in it

• Traceability: 90 links. System requirements are derived from the requirements specification and the safety goals, test cases verify requirements. Some requirements are deliberately not verified or have no link, so that coverage and metrics have something to show.
• Suspect links: After a change to the specification (fast charging in 18 instead of 20 minutes), four links are marked as suspect.
• Baselines: v1.0 (quotation state, approved by quality assurance) and v1.1 (after specification revision B). The comparison shows exactly seven differences.
• Review: “Review Schutzfunktionen v1.1” with approvals, one rejection with reason and one open comment.
• Change request: ÄA-1 “Schnellladezeit von 20 auf 18 Minuten verkürzen” (reduce fast charging time from 20 to 18 minutes), accepted, with impact list.
• Comments with @mention between the people of the sample company.
• Deliberately weak wording in five requirements, where the wording check takes effect (e.g. “möglichst genau”, “Details TBD”).

People of the sample company

Person	Role in the group	Task in the example
Claudia Brandt	ADMIN	project management, decides on change requests
Anna Keller	EDIT	systems engineer, submits the change request
Bernd Vogel	COMMENT	quality assurance, approves baselines

Note: The former requirements specification templates (welding fixture, passive balancer and others) have been discontinued. They only covered one level without traceability. You create your own templates by copying a project (Creating and managing projects).