Splitting Functions from Implementation: Layered Verification in Automotive E/E Architecture

Function vs Requirement: The Foundation of Layered Decomposition

The discussion opens with a core tension: architecture must start from functions but cannot cover all of them. Alex asks whether ignoring some functions loses them, and stresses that bidirectional traceability between requirements and architecture is the prerequisite to avoid omissions.

Carl clarifies the terminology: a function is an implementation-independent expected behavior, while a requirement is a sub-behavior in the function specification. Validation confirms the upper-level requirement; verification checks the lower-level implementation. This distinction gives a theoretical basis for function selection — architecture design decomposes vague upper-level functions into concrete, verifiable lower-level requirements.

Carl adds that architecture design aims to decompose and allocate upper-level requirements, define specific requirements for architecture elements, and argue that the element composition satisfies the upper-level needs. If existing test means cannot verify an implementation, decomposition continues until requirements become testable. The granularity of architecture elements (system, component, unit) is determined by the architecture level: system-level elements correspond to vehicle architecture, component or unit elements to system architecture.

Three Core Architecture Layers: "What" vs "How"

Carl defines three key layers: system architecture, software architecture, and hardware architecture. System architecture is implementation-agnostic, focusing only on the expected behavior of system elements and their relationships — answering "what it should become." Software and hardware architectures are implementation-related, focusing on concrete realization steps — answering "how to do it." Leo summarizes the logic: "Upward is behavior, downward is implementation."

Carl notes that system architecture design operates at a high abstraction level, requiring years of implementation-layer experience. Overseas chief engineers in their 50s-60s focus on this layer, and its design quality directly determines downstream R&D efficiency and cost — a fundamental gap between domestic and international practice.

Standards Implementation and Tool Selection: Theory vs Practice

Chen describes an ideal flow: TSR (Technical Safety Requirements) kept coarse-grained, refined in TSC (Technical Safety Concept) phase, then passed to software and hardware layers. Zhao admits that in real projects system requirements are often rough; achieving fine-grained constraints at TSC stage is already considered high quality.

Huo compares mainstream tools:

Preevision : functional and logical architecture as hierarchical modules, customizable whether to distinguish them.

SystemWeaver : two levels, elements linked by many-to-many allocation rather than refinement; actual associations tend to be fuzzy.

Arcadia Capella : clearest design — logical architecture is a further split of functional architecture, enabling visual detection of functional chain intersections and preventing unintended function triggers, greatly simplifying architecture complexity.

Huo emphasizes the importance of logical architecture with a concrete fault case: an emergency high-voltage power-down function triggers power-mode shutdown, which turns off headlights, causing simultaneous loss of propulsion and lighting while driving. The root cause was that designers only identified direct functional associations and did not use logical architecture to trace indirect associations, leading to unintended behavior — proving logical architecture's critical role in complex functional chain analysis.

Carl adds that such faults are essentially inconsistent requirement logic among system architecture elements, making the design unimplementable — a typical issue in domestic architecture design.

Mapping Functional and Logical Architecture: Requirements as the Core Link

Chen proposes that functions are collections of requirements, better allocated to logical architecture elements; the functional-to-logical mapping should emerge automatically from requirement allocation.

Huo, drawing on Arcadia theory, says functional architecture requirements describe external system behavior, while logical architecture decomposes internal implementation; their link must be analyzed per requirement type. Chen analogizes to time-domain vs frequency-domain signals: both belong to one system, need no direct mapping, only separate requirement descriptions to enable design and utilization — offering a flexible implementation perspective.

Practitioners further detail mapping operations: functional architecture represents external system capabilities, logical architecture provides internal capability support, requirements are the bridge. Precise requirement allocation prevents architecture disconnect. Complex functions decompose into multiple sub-requirements allocated to different logical elements, interacting to realize the overall function, strictly following bidirectional traceability to ensure no missing requirements and no logical conflicts.

For the high-voltage power-down fault, an optimization is proposed: during logical architecture design, establish a functional impact chain analysis mechanism. For critical safety functions like high-voltage power-down, not only direct associations but also indirect vehicle electrical loads must be examined. Requirement constraints should specify "non-essential electrical devices power off first, critical safety devices delay power-off" — mitigating unintended risks at architecture level, aligning with ISO 26262 functional safety design core requirements.

Another practitioner notes a common domestic pitfall: "heavy function listing, light logical decomposition" — directly mapping functions to hardware components, skipping requirement layering and logical architecture design, causing massive compatibility issues during software-hardware integration, further evidencing the importance of high-abstraction system architecture design.

Conclusion

The discussion covers function selection, requirement verification, layer distinctions, and tool application in automotive electronic architecture design. It clarifies the "function–requirement–implementation" layered logic, highlights practical pain points in standards adoption and tool usage, reveals the domestic-international gap in high-abstraction architecture capability, and provides actionable fault-optimization ideas and architecture mapping techniques. Automotive E/E architecture design, as the core of vehicle R&D, must balance theoretical rigor with practical flexibility: using layered verification as the central method, tools as implementation support, requirements as the mapping link, supplemented by functional impact chain analysis, so that architecture truly serves vehicle function realization and iteration, fundamentally improving automotive electronic system safety and reliability.