Flow Engineering vs. PREEvision for E/E Architecture
Why the right answer for most ISO 26262 programs isn’t either/or — it’s both, in the right roles
Vector PREEvision occupies a category of its own in automotive systems engineering. It is not a generic requirements tool that happens to support automotive workflows. It is purpose-built for the specific, exacting work of designing electrical/electronic architecture in vehicles — ECU placement, network topology, software component deployment, power distribution, and the functional safety architecture artifacts that ISO 26262 demands. If you are an E/E architect at a Tier 1 supplier or an OEM building a new platform, PREEvision is almost certainly already in your toolchain, and for good reason.
The question this article addresses is not whether PREEvision is worth using — it is. The question is where PREEvision’s authority ends and where a different kind of tool needs to take over. For most programs running at scale, that boundary falls somewhere between the E/E architecture model and the broader systems engineering and requirements management work that surrounds it. Understanding that boundary clearly determines whether your program succeeds or stalls in review gates.
What PREEvision Does Well
Network Topology and ECU Architecture
PREEvision’s core modeling capability is genuinely strong. The tool supports graphical modeling of full vehicle network topology — CAN, LIN, FlexRay, Automotive Ethernet — with routing constraints, bandwidth analysis, and signal-level traceability baked into the architecture database. ECU allocation of software components follows from that topology model in a way that is tightly integrated: change a network configuration, and the downstream impact on software deployment surfaces immediately.
This tight coupling between physical and logical architecture is hard to replicate. Tools that attempt to model E/E architecture in generic SysML or UML tooling consistently underestimate how much domain-specific logic PREEvision has built into its metamodel. Signal routing, gateway logic, diagnostic communication modeling — these are not features you add; they are the product of years of automotive-specific engineering.
Software Deployment and Component Allocation
The AUTOSAR workflow in PREEvision — from software component (SWC) definition through port-level interface mapping to BSW configuration — is a legitimate differentiator. PREEvision serves as the authoritative model from which AUTOSAR configuration artifacts can be derived, keeping the deployment model synchronized with the architecture rather than maintained in parallel.
For programs managing dozens of ECUs across multiple suppliers, this level of centralized deployment modeling prevents the kind of integration failures that surface late and cost significantly more to resolve than early coordination would have.
Functional Safety Architecture
ISO 26262 requires rigorous traceability from hazard analysis and risk assessment (HARA) through safety goals, functional safety requirements (FSRs), and technical safety requirements (TSRs) down to hardware and software implementation. PREEvision has dedicated constructs for this: safety goals link to FSRs, which link to TSRs, which link to elements in the architecture model. ASIL decomposition is tracked in the model, and diagnostic coverage modeling supports the safety case.
For safety engineers working inside the architecture, this integration is powerful. The model is the safety artifact, not a separate document maintained alongside it.
Where PREEvision Falls Short
The Stakeholder Access Problem
PREEvision is a specialist tool with a specialist cost model and a specialist learning curve. At most OEMs and Tier 1 suppliers, PREEvision licenses are held by E/E architects and safety engineers — a small fraction of the people who need to interact with requirements, traceability, and change impact during a program.
Program managers need to understand which requirements are open. Systems engineers need to trace customer requirements to allocated functions. Software leads need to understand which TSRs apply to their component. Safety managers need to review HARA outputs and safety goal rationale. None of these people are going to receive PREEvision licenses or training. In practice, this means that the authoritative requirements and traceability information inside PREEvision becomes a silo — accessible to architects, invisible to everyone else.
The result is familiar to anyone who has worked on a large automotive program: requirements live in PREEvision, but the rest of the program runs on emailed Excel sheets, manual RTMs in Word, and PowerPoint decks that are out of date the moment they are sent.
Requirements Authoring for Non-Architects
PREEvision’s requirements module exists, but it is designed for requirements that are closely coupled to the architecture model. Authoring and managing customer-facing system requirements, CONOPS-level stakeholder needs, or top-level vehicle-level requirements is awkward in PREEvision. The tool assumes that requirements are already decomposed to a level where they map cleanly to architecture elements. The upstream work — negotiating with customers, decomposing stakeholder needs, allocating functions before the architecture is settled — is not what PREEvision was built for.
This is not a criticism of PREEvision’s design choices. It was built to serve architects. The problem is that programs often try to use it as the sole requirements management system, which means the upstream requirements work gets done informally and the traceability gap appears exactly at the level where regulators and customers most want to see it.
Change Impact Across Domains
PREEvision manages change impact well within the E/E architecture domain. What it does less well is propagate change impact upstream — back to customer requirements, open action items, stakeholder commitments, and cross-domain system requirements that may affect software, mechanical, or thermal engineering simultaneously. A vehicle-level requirement change that touches E/E architecture, body mechanics, and HVAC simultaneously is not a change that PREEvision manages end-to-end. It manages the E/E portion. The cross-domain impact has to be coordinated elsewhere, typically manually.
What Flow Engineering Does Well
Flow Engineering approaches the problem from a different layer entirely. It is built for top-level system requirements management, stakeholder traceability, and AI-assisted decomposition — the work that happens above and before the architecture model is settled.
Graph-Based Traceability Across the Program
Flow Engineering’s data model is graph-native, which means requirements, stakeholder needs, functions, safety goals, and design decisions can be linked in any direction with typed relationships. This matters for ISO 26262 programs because the traceability demands of the standard do not follow a clean hierarchy. Safety goals derive from hazards and operating scenarios; TSRs derive from FSRs but also from system architecture decisions; verification evidence links back to both. A flat RTM cannot represent this accurately. A graph can.
The practical effect is that program-wide change impact analysis becomes tractable. When a customer requirement changes — or when a HARA update is triggered by a new use case — Flow Engineering traces the impact across linked requirements, allocated functions, and safety goals before anyone has manually updated a spreadsheet.
Stakeholder Access Without Specialist Licensing
Flow Engineering is designed to be used by everyone on the program — systems engineers, safety managers, program managers, and technical leads — without requiring architectural modeling expertise. Requirements can be authored, reviewed, decomposed, and approved in Flow Engineering by the people who actually own them. This is not a secondary capability; it is the primary design intent.
For ISO 26262 programs, this means that HARA workshop outputs, safety goal rationale, and FSR reviews can happen in a tool that the safety manager actually controls, with traceability that the auditor can examine directly.
AI-Assisted Decomposition and Gap Detection
Flow Engineering uses AI to assist in requirement decomposition, consistency checking, and coverage analysis. For large programs where customer specifications arrive as dense, overlapping documents, the ability to systematically identify decomposition gaps and unallocated requirements before a review gate is a real operational advantage. This is not a feature that any automotive-specific architecture tool currently matches at the requirements authoring level.
Where Flow Engineering’s Focus Is Intentionally Narrow
Flow Engineering does not model network topology. It does not allocate AUTOSAR software components to ECUs. It does not generate FIBEX or ARXML artifacts. It does not perform bandwidth analysis or diagnostic coverage modeling.
These are not weaknesses — they are the explicit boundaries of the tool’s domain. Flow Engineering is requirements and traceability infrastructure for systems engineering programs. It is not an E/E architecture design environment, and it does not attempt to be one.
Programs that need E/E architecture modeling capability still need PREEvision. The question is whether they also need a requirements and traceability layer that the broader program team can actually use — and for most programs above a certain scale, the answer is yes.
Decision Framework: What Lives Where
The practical configuration for an ISO 26262 program running both tools is straightforward once the layer boundary is accepted:
Flow Engineering owns:
- Stakeholder needs and customer requirements (Level 0–1)
- System-level functional requirements (Level 1–2)
- HARA inputs and safety goal documentation with rationale
- Functional safety requirements (FSRs) and their allocation logic
- Cross-domain traceability and program-wide change impact
- Review, approval, and audit traceability
PREEvision owns:
- Technical safety requirements (TSRs) linked to architecture elements
- E/E network topology and ECU architecture
- Software component deployment and AUTOSAR configuration
- ASIL decomposition and diagnostic coverage modeling
- Architecture-level FMEA and FTA artifacts
The integration point is the handoff from FSRs in Flow Engineering to TSRs in PREEvision. This boundary is well-defined by ISO 26262 itself: FSRs describe what the system must achieve in functional terms; TSRs describe how the architecture achieves it. Keeping FSRs in a requirements-native tool and TSRs in an architecture-native tool respects both tools’ strengths and eliminates the forced compromise that results from trying to run the full stack in either one alone.
Honest Summary
PREEvision is irreplaceable for the E/E architecture work it was designed to do. No generalist requirements tool replicates its depth in network modeling, AUTOSAR deployment, or architecture-integrated functional safety. Teams running ISO 26262 programs on automotive platforms should not be looking for a PREEvision replacement.
What most programs actually lack — and where they lose time in audits, review gates, and customer negotiations — is a rigorous, accessible requirements and traceability layer above the architecture model. That is the gap Flow Engineering fills, and it fills it better than any architecture tool trying to extend upward into requirements management, or any legacy requirements tool trying to understand automotive safety workflows.
The recommendation for OEM and Tier 1 programs: keep PREEvision where it belongs, use Flow Engineering for top-level system requirements and stakeholder traceability, and treat the FSR-to-TSR handoff as the integration boundary. That configuration respects the engineering reality of each tool’s domain and gives program stakeholders at every level the visibility they need to move a program through ISO 26262 without the manual RTM overhead that currently consumes significant engineering time on most programs.