Hello everyone! Today I’d like to discuss one of the hottest topics in the modern automotive industry: requirements engineering for electronic and electrical (E/E) systems. I’d like to share insights and practical strategies I’ve gathered from over a decade of working in this field.
The Challenge of Modern Automotive E/E Systems
Look inside any modern car today, and you’ll find a complex array of electronic systems—from ADAS to battery management systems—that were unimaginable just a few years ago. My colleague jokingly refers to modern vehicles as “computers on four wheels,” and that’s not far from the truth. Software and electronic systems have become increasingly crucial.
When developing these complex systems, ‘Requirements Engineering (RE)’ is absolutely essential. To use a construction analogy, even the most skilled builders can’t create a perfect building with flawed blueprints. The same applies to automotive E/E system development.
Structuring Requirements with Three Views
To effectively manage complex systems, the industry typically uses a 3-View Framework. When I first encountered this concept, I found it somewhat confusing, but now I appreciate its utility every day.
Functional View
This essentially answers “what should the system do?” For example:
- “Provide a warning sound when the driver deviates from the lane”
- “Limit charging current when battery temperature exceeds 60°C”
These requirements are typically documented in URS (User Requirements Specification) or SyRS (System Requirements Specification).
Logical View
This addresses “how will that functionality be implemented?” Examples include:
- Algorithms for processing camera images to detect lanes and determine deviation
- Logic for calculating control commands when temperature sensor data exceeds thresholds
At this stage, we focus on structuring system behavior in terms of software or algorithmic units rather than specific hardware.
Physical View
Finally, we define “what hardware will implement this?” such as:
- ADAS ECU communicating warnings to EPS ECU via CAN messages
- BMS sending control commands to charging controller in specific message formats
In actual projects, these three perspectives must be connected through traceability. Traceability is the link showing how requirements connect to one another, and without it, impact analysis of changes becomes nearly impossible.
Goal-oriented vs. Logic-based: A Balanced Approach
There are two approaches to writing requirements, each with their own strengths and weaknesses.
Goal-oriented
This emphasizes the ultimate objectives, such as “Protect passengers during collision.” This approach is excellent for showing team members the big picture and direction, but if it’s too abstract, implementation and verification can become challenging.
Logic-based
This specifies concrete logic, such as “Deploy airbags within 50ms if impact sensors detect forces exceeding 30G.” This provides clear implementation guidelines but can sometimes be too detailed, causing developers to miss the overall purpose or reducing flexibility.
In my experience, a hybrid approach works best. Begin with goal-oriented requirements and gradually make them more specific with logic-based details. It’s similar to writing a book—start with an outline and progressively fill in the details.
Cultural Differences Among OEMs
Working in the automotive industry, you quickly discover that different OEMs approach requirements differently.
German OEMs generally prefer formalized, logic-based requirements. They believe everything should be clearly defined and quantified. Japanese OEMs, on the other hand, tend to present goal-oriented requirements based on trusted partnerships, then work together to elaborate the details.
Korean OEMs are developing a hybrid approach, gradually adopting global standards while incorporating the strengths of both methods. Personally, I find this balanced approach most practical.
Practical Requirements Management Strategies
Now let’s examine how requirements are managed in practice.
1. Using Templates and Checklists
Standardized templates greatly help maintain quality and consistency in requirements. Our team uses different templates for functional, logical, and physical perspectives, with appropriate checklists for reviewing each type.
2. Ensuring Traceability
We manage connections between requirements using ALM (Application Lifecycle Management) tools like DOORS, Polarion, or JAMA. These tools are invaluable for impact analysis of changes. I recall once identifying all requirements affected by a battery temperature sensor specification change in just minutes—something unimaginable without these tools.
3. Requirements Quality Criteria
Good requirements should have these characteristics:
- Clarity: No room for interpretation
- Completeness: All necessary information included
- Consistency: No conflicts with other requirements
- Verifiability: Objective confirmation of fulfillment
- Traceability: Clear relationships with other requirements
4. Common Mistakes
Mistakes I frequently observe in the field include:
- Using ambiguous terms like “quickly” or “appropriately”
- Requirements that overly dictate implementation methods
- Conflicting or duplicative requirements
- Conditions that are practically impossible to verify
- Missing traceability between requirements
Functional Safety and Requirements Engineering
Functional Safety is a critical element in automotive E/E systems. According to ISO 26262, requirements should follow this hierarchical structure:
- Safety Goal (SG): High-level safety objectives like “Airbags must deploy promptly in collision situations to protect passengers”
- Functional Safety Requirements (FSR): “The airbag system must deploy airbags within 45ms after collision detection”
- Technical Safety Requirements (TSR): “When impact sensors detect forces of 30G or higher, the ECU must generate an airbag deployment signal within 10ms”
The hybrid approach applies here too—SGs are goal-oriented while TSRs are logic-based. Additionally, all requirements must maintain bidirectional traceability through implementation and testing.
Industry Trends and Future Challenges
1. The Era of Software-Defined Vehicles (SDV)
In the SDV era exemplified by Tesla, requirements continue to evolve post-release through OTA updates. This presents significant challenges to traditional requirements management approaches. Architecture-centered RE and DevOps integration have become essential.
2. Harmonizing Agile and Safety Standards
The rapid development cycles of agile methodologies often conflict with the strict documentation and traceability requirements of ISO 26262. Hybrid methodologies like SAFe (Scaled Agile Framework) or Agile V-model are gaining attention as potential solutions.
3. Implementing Domain-Specific Languages (DSL)
Efforts to reduce the ambiguity of natural language through domain-specific languages (DSLs) are increasing. These allow requirements to connect directly with test automation or formal verification.
4. AI-Based Automation Tools
There’s growing use of AI and natural language processing to automate requirements quality checks, test case generation, and identification of missing information. Companies like Continental have reportedly succeeded in significantly reducing requirements analysis time using AI, though human review remains essential.
Practical Challenges and Solution Strategies
Many engineers struggle with requirements engineering in the following ways:
Abstraction Confusion
Many engineers are unfamiliar with the functional-logical-physical structure. Our team regularly conducts workshops using real project examples to help engineers grasp these concepts.
Lack of Traceability
ALM tools require more than just implementation—they need company-wide training and continuous management. Traceability breaks if only one department maintains it while others don’t follow suit.
Inconsistency Between Requirements
Model-Based Systems Engineering (MBSE) tools for automatic verification and consistency analysis with test cases are highly effective. Models allow visual confirmation of requirement consistency.
Overcoming Interpretation Differences
To help team members with diverse backgrounds understand requirements consistently, we utilize visual models like SysML/UML, shared glossaries, and effective collaboration tools.
Conclusion and Practical Recommendations
To succeed in complex automotive E/E system development, try implementing these strategies:
- Adopt a hybrid requirements writing approach – Start with goal-oriented requirements and gradually make them more specific with logic-based details.
- Utilize the MBSE-based 3-View structure – Separating functional, logical, and physical perspectives greatly helps manage complexity.
- Develop flexible RE processes for SDV and agile methodologies – Process innovation is necessary for future automotive development environments.
- Ensure complete traceability for functional safety requirements – In safety-critical systems, all connections from SGs to tests must be clear.
- Actively use AI and ALM tools – Leverage technology to improve requirements quality and work efficiency.
- Establish communication strategies to reduce interpretation differences between departments – Minimize misunderstandings through common language and visualization tools.
- Encourage continuous learning and application of changing standards and tools – This field evolves rapidly, requiring continuous adaptation.
Requirements engineering is not just document creation—it’s foundational work for successfully building complex systems and a creative problem-solving process. Well-defined requirements prevent many potential development issues, ultimately contributing to safer and more efficient automotive E/E systems.
I hope these strategies prove helpful in your projects. If you have questions or comments, please leave them below!
From this post onwards, I will be adding podcasts created via Google Notebook lm.