Einfache, schnelle Oberfläche
Gebaut für die Prüfung, nicht für die Dateneingabe. Tastatur-first-Navigation, Sammelaktionen und Warteschlangen, die zeigen, was Ihre Aufmerksamkeit braucht.
Requirements Manager extrahiert Anforderungen aus rohen Spezifikationen und klassifiziert jede einzelne auf dem Niveau von Fachexperten. Der Startpunkt für den Produktlebenszyklus.
The Battery Management System (BMS) shall provide comprehensive monitoring, control, and protection for the high-voltage battery system installed in E-Platform Gen3 vehicles. All electrical requirements defined in this section shall be validated against the reference architecture (PLT-EPG-003) and shall comply with applicable EMC standards per LV 124 and CISPR 25.
3.2.1 The BMS shall monitor individual cell voltages with an accuracy of ±5mV across the full operating temperature range (−40°C to +65°C). Measurement sampling rate shall be ≥10Hz during active vehicle states. Reference: ISO 18300.
3.2.2 Active cell balancing shall maintain voltage delta below 20mV across all series-connected cells during both charge and discharge cycles. The balancing algorithm shall achieve equalization within 4 hours under standard conditions as defined in test procedure TP-BMS-042.
3.3.1 The system shall disconnect the HV battery within 50ms upon detecting a critical isolation fault (resistance < 100Ω/V). This requirement is classified ASIL-C per ISO 26262-3.
3.3.2 All safety-relevant BMS functions shall comply with ISO 26262 ASIL-C requirements. Redundant monitoring paths shall be provided for all critical measurements including cell voltage, pack current, and isolation resistance.
3.4.1 Battery state of charge (SoC), state of health (SoH), and fault status shall be transmitted via CAN bus (FlexRay backup) with a maximum cycle time of 100ms during driving states.
Table 3-1: BMS CAN Signal Matrix
| Parameter | CAN Signal | Cycle | Resolution |
|---|---|---|---|
| Cell Voltage | BMS_CellV | 100ms | 1mV |
| Pack Current | BMS_PackI | 50ms | 0.1A |
| Temperature | BMS_Temp | 500ms | 0.5°C |
| State of Charge | BMS_SoC | 100ms | 0.1% |
3.5.1 The battery pack assembly shall maintain full operational capability within an ambient temperature range of −40°C to +65°C without degradation in performance or safety characteristics…
Gebaut für die Prüfung, nicht für die Dateneingabe. Tastatur-first-Navigation, Sammelaktionen und Warteschlangen, die zeigen, was Ihre Aufmerksamkeit braucht.
Jede Klassifizierung kommt mit einer Begründung in Klartext und nennt die früheren Anforderungen hinter jeder Entscheidung.
Springen Sie von jeder Anforderung zurück zu ihrem Quelldokument, zur Seite und zum Abschnitt. Kein Suchen in PDFs.
Keine Einrichtung nötig, um mit dem Extrahieren zu starten. Ontologie-Zuordnungen konfigurieren Sie später, nur wenn Sie sie brauchen.
ReqIF, Word, PDF, Excel. Strukturiert oder unstrukturiert, ohne Vorverarbeitung.
Übergeben Sie klassifizierte Anforderungen an PLM, ALM oder eine einfache Tabelle für nachgelagerte Teams.
Vergleichen Sie tausende eingehende Anforderungen mit früheren Programmen. SPREAD trennt, was abgedeckt ist, was neu ist, was nur teilweise passt und was im Widerspruch zur bekannten Engineering-Realität steht.
Eine Anforderung als abgedeckt, teilweise, widersprüchlich oder neu zu klassifizieren ist subjektive Arbeit. Erfahrene Ingenieure sind bei Grenzfällen uneins, besonders bei der Linie zwischen teilweise und widersprüchlich. Deshalb messen wir SPREAD an der Übereinstimmung der Experten selbst, der echten menschlichen Obergrenze für diese Aufgabe.
SPREAD stimmt mit Fachexperten so oft überein, wie Experten untereinander übereinstimmen. Wir messen die Parität, nicht die absolute Genauigkeit, weil subjektive Grenzen nicht gegen eine erdachte einzige Wahrheit geprüft werden können.
Stratifizierter Benchmark über die Domänen Sicherheit, Performance und Schnittstellen im Automobilbereich. Expertenlabel zum Konsens entschieden.
Die Grenze zwischen teilweise und widersprüchlich ist tatsächlich mehrdeutig. SPREAD legt diese Fälle mit kalibrierter Konfidenz zur Prüfung offen, statt vorzugeben, die Grenze sei eindeutig.
Statt einer weiteren isolierten Tabellenzeile wird jede Anforderung mit Ihren Entwicklungsdaten verknüpft: betroffene Systeme, implementierte Funktionen, Varianten, Normen, Tests und frühere Programme.
Verarbeitet PDFs, Ausschreibungen, Normen und Spezifikationsdokumente ohne manuelle Bereinigung oder Vorverarbeitung.
Extrahiert Anforderungskandidaten, klassifiziert die technische Bedeutung und bewahrt die Rückverfolgbarkeit zur Quelle für die Prüfung.
Verknüpft jede Anforderung mit Ihrer Engineering-Ontologie: Funktionen, Komponenten, Tests, Varianten und frühere Programme.
Markiert jede Anforderung als abgedeckt, teilweise, widersprüchlich oder neu, sodass Ingenieure entscheiden, bevor Architektur- und Lieferarbeit das Risiko erben.
Buchen Sie eine 20-minütige Tour.
Wir bilden einen echten Anforderungs-Workflow ab und zeigen, wo SPREAD an Ihre Produkt-Ontologie andockt.