[System Architecture] #1. The First Step in Designing a 'Computer on Wheels': Everything About The Functional View

Q: Is a Functional View really necessary? Can't I just start coding?

👉 For a small project, maybe. But for a car system with hundreds of intertwined ECUs, it's nearly impossible. Starting without a Functional View is highly likely to lead to bigger problems later, like feature conflicts, missed requirements, and testing difficulties. Think of it as paving the road properly from the start.

Q: If you had to pick one, what's the most important principle when creating a Functional View?

👉 If I had to choose just one, I'd say 'Hierarchical Decomposition.' Breaking down a huge function into manageable, logical pieces is the start of all good design. The more you break it down, the clearer each function's responsibility becomes, and the easier it is to reuse or change.

Q: How will the Functional View evolve in future automotive architectures?

👉 Excellent question! In the future, Service-Oriented Architecture (SOA), where functions are abstracted as 'services,' will become mainstream. Therefore, the Functional View will likely evolve from defining static signal flows to defining a 'service catalog' and API interfaces accessible from anywhere on the network.

If You Don’t Know the ‘Functional View’ in Automotive E/E Architecture, You’re in Trouble! These days, a car isn’t just a ‘machine’; it’s a ‘computer on wheels,’ right? I’ll explain the core design compass, the ‘Functional View,’ that helps you not get lost amidst countless functions and complex software.

Hello to all the engineers responsible for automotive E/E system design! With ADAS, electrification, and connectivity, new features are being added every day, making the Electrical/Electronic (E/E) system as complex as a jungle. I’ve often found myself thinking, ‘How do I manage all this?’ This is where you need a compass that shows the big picture of the system: the Functional View. The Functional View is a powerful tool that answers the fundamental question, ‘So, what is this system supposed to do?’ Today, let’s dive deep into everything about it! 😊

Table of Contents

So, What Exactly is a ‘Functional View’? 🤔

To put it simply, the Functional View is like drawing a blueprint that focuses only on ‘What the system should do.’ What hardware or software to use is a later problem; the first step is to clearly define the system’s goals and operations in functional units. It’s like deciding on the key actions in a recipe, such as ‘prep ingredients,’ ‘boil,’ and ‘stir-fry,’ before anything else.

💡 Good to Know!
Using a Functional View allows you to clearly communicate the intent of a complex system, track requirements to ensure nothing is missed, predict issues before system integration, and even increase testing efficiency. It’s a triple-win!

Functional, Logical, Physical View? What’s the Difference? 📊

When designing a car’s system architecture, we usually draw three types of blueprints. These are the Functional, Logical, and Physical Views, and each has a different role.

View	Viewpoint	Key Question
Functional View	The most abstract level; system’s behavior and goals	What should it do?
Logical View	Logical structure of software/hardware to implement functions	How should it be structured?
Physical View	Physical placement of actual ECUs, sensors, networks, etc.	Where will it run?

Typically, the design is detailed in the order of Functional View → Logical View → Physical View. This hierarchical approach is very advantageous for ensuring design consistency and traceability.

Core Principles of a ‘Well-Drawn’ Functional View 📝

To create an effective Functional View, it’s important to follow a few principles. Let me share some that I find crucial in practice.

Functional View Best Practices 🏆

Hierarchical Decomposition: Continuously break down large functions into smaller units to make them manageable. It’s best if each function has a single responsibility.
Clear Input/Output: Every function must have clearly defined inputs and outputs. This allows for tracing the data flow.
Requirements Traceability: All functions should have a link back to the requirement they originated from, answering ‘why’ they were created.
Verifiability: Instead of vague statements like ‘works well,’ define functions with specific, testable criteria, such as ‘response time under 10ms.’

⚠️ Be Careful!
The Functional View should not be dependent on specific technologies or platforms. Details like ‘Chip from Company A’ or ‘OS from Company B’ belong in the Logical or Physical View. This is a crucial principle for ensuring the reusability and flexibility of functions!

Functional Safety (ISO 26262) and the Functional View 🛡️

For automotive engineers, ‘safety’ is a non-negotiable value. The international standard for functional safety, ISO 26262, also emphasizes the importance of the Functional View.

Through the Functional View, you can assign an ASIL (Automotive Safety Integrity Level) to each function and incorporate safety mechanisms (e.g., fault diagnosis, monitoring functions) into the design to achieve Safety Goals. For example, for a safety-critical function like vehicle speed information (ASIL B), you can pre-define at the functional level how to generate alternative data and maintain the system in a safe state if the primary signal fails. This is a huge help in ensuring all safety requirements are met and verified.

💡

Functional View: Key Summary

✨ Perspective: The top-level blueprint focusing on ‘What’ to do.

📊 Role: A compass that translates requirements into functions and aids understanding of complex systems.

🔗 Design Flow:

Functional View (What) → Logical View (How) → Physical View (Where)

🛡️ Safety: The starting point for ISO 26262 safety design, incorporating ASILs and safety mechanisms.

In the era of Software-Defined Vehicles (SDVs), the importance of the Functional View is only growing!

Frequently Asked Questions ❓

Q: Is a Functional View really necessary? Can’t I just start coding?

A: For a small project, maybe. But for a car system with hundreds of intertwined ECUs, it’s nearly impossible. Starting without a Functional View is highly likely to lead to bigger problems later, like feature conflicts, missed requirements, and testing difficulties. Think of it as paving the road properly from the start.

Q: If you had to pick one, what’s the most important principle when creating a Functional View?

A: If I had to choose just one, I’d say ‘Hierarchical Decomposition.’ Breaking down a huge function into manageable, logical pieces is the start of all good design. The more you break it down, the clearer each function’s responsibility becomes, and the easier it is to reuse or change.

Q: How will the Functional View evolve in future automotive architectures?

A: Excellent question! In the future, Service-Oriented Architecture (SOA), where functions are abstracted as ‘services,’ will become mainstream. Therefore, the Functional View will likely evolve from defining static signal flows to defining a ‘service catalog’ and API interfaces accessible from anywhere on the network.

The Functional View is the blueprint for a complex automotive E/E system! It might seem a bit daunting at first, but once you have it properly drawn, it will serve as a reliable guide throughout the development process. I hope today’s content was a little helpful for your work. If you have more questions, feel free to ask in the comments! 😊

[System Architecture] #1. The First Step in Designing a ‘Computer on Wheels’: Everything About The Functional View