Flow Engineering vs. PREEvision: Requirements-First vs. Architecture-Deep
The Wrong Comparison
When automotive systems engineers debate Flow Engineering against PREEvision, they are usually framing a real frustration as a false choice. The frustration is legitimate: requirements are scattered, traceability is manual, safety cases take weeks to assemble, and the tool stack feels like it was assembled by different vendors in different decades — because it was.
The framing is false because PREEvision and Flow Engineering do not answer the same question. PREEvision asks: given a defined system architecture, how do we model, configure, and validate the electrical/electronic design down to network topology, AUTOSAR software components, and ISO 26262 work products? Flow Engineering asks: how do we capture, structure, and connect the stakeholder and system requirements that should be driving that architecture in the first place?
These are sequential questions. Conflating the tools that answer them creates the exact problem teams are trying to solve.
What PREEvision Does Well
PREEvision, developed by Vector Informatik, is purpose-built for automotive E/E architecture engineering. It is not a general-purpose systems engineering tool that happens to support automotive workflows — it is the inverse: a domain-specific platform that has accumulated two decades of automotive-specific modeling depth.
E/E architecture modeling. PREEvision supports a full model-based representation of a vehicle’s electrical and electronic architecture — ECUs, wiring harnesses, power distribution, network topologies (CAN, LIN, Ethernet, FlexRay), and their interconnections. Engineers can evaluate architecture variants, run topology optimizations, and generate harness data that feeds directly into manufacturing. This is not metadata about a system; it is the system model.
AUTOSAR configuration. For teams working in Classic or Adaptive AUTOSAR, PREEvision provides native configuration support. Software components, interfaces, runnable entities, and communication matrices can be modeled and exported in ARXML format compatible with downstream toolchains. The integration with Vector’s broader ecosystem — CANdb++, CANoe, DaVinci — is genuine and tested at scale. Teams doing AUTOSAR work in PREEvision are not fighting the tool.
ISO 26262 work products. PREEvision includes structured support for Hazard Analysis and Risk Assessment (HARA), ASIL decomposition, safety goals, and functional safety concepts. The tool can trace from safety goals through technical safety requirements into the architecture model, and it generates the work product documentation formats that certification authorities expect. For a Tier 1 supplier building a safety-critical ECU, this is not a feature list — it is the daily workflow.
Variant management at automotive scale. Modern vehicles involve hundreds of option variants that cascade through software, hardware, and network configuration. PREEvision has mature variant management that handles this combinatorial complexity in a way that general-purpose tools consistently fail to replicate.
Where PREEvision Falls Short
PREEvision’s depth in E/E architecture comes with a narrow entry point. The tool is most valuable once you have a clear system decomposition, defined safety goals, and a functioning architecture concept. It does not help you get there.
It assumes requirements exist upstream. PREEvision can store and link requirements — it has a requirements module — but structuring stakeholder needs, decomposing functional requirements, building the logical architecture that precedes the physical one, and maintaining bidirectional traceability across that chain is not where the tool excels. Teams that try to use PREEvision as their requirements management system discover this quickly.
Onboarding cost is high and domain-specific. PREEvision requires automotive E/E domain expertise to use effectively. An engineer who is excellent at systems requirements but new to AUTOSAR or harness topology will face a steep learning curve. This is appropriate for an E/E architect; it is a barrier for anyone trying to use the tool higher in the V-model.
Collaboration outside the E/E team is difficult. PREEvision is a client-server tool with a desktop-heavy workflow. Stakeholders outside the E/E architecture group — systems engineers, safety managers, program managers, customer interface teams — have limited ability to participate meaningfully. Requirements reviews, change impact discussions, and traceability audits often devolve into PowerPoint exports and email threads.
It does not address the upstream incoherence. If your stakeholder requirements are in Word documents, your functional requirements are in a legacy DOORS database, and your system architecture decisions live in someone’s head, PREEvision inherits that incoherence. It cannot fix what it receives.
What Flow Engineering Does Well
Flow Engineering operates at the systems requirements layer — the domain that PREEvision assumes is resolved before its work begins. Its core design is graph-based and AI-native, meaning requirements, their relationships, and their rationale are structured as a connected model from the start, not retrofitted into one.
Graph-based requirements modeling. Where document-based tools store requirements as rows in a database with manual link tables, Flow Engineering represents requirements, system functions, hazards, design decisions, and verification methods as nodes in a connected graph. This structure is not cosmetic — it changes what questions you can ask and how quickly you can answer them. Impact analysis, coverage gaps, and traceability completeness are computational results, not manual audits.
AI-native requirement authoring and review. Flow Engineering uses AI to assist in drafting, decomposing, and reviewing requirements against quality criteria (ambiguity, testability, completeness, consistency). For teams that currently spend engineering hours manually scrubbing requirements documents before handing off to suppliers or safety auditors, this reduces cycle time measurably. The AI assistance is embedded in the authoring workflow, not bolted on as a separate review pass.
Readable traceability for non-specialist stakeholders. Because Flow Engineering is a modern SaaS platform with an interface designed for collaborative review, stakeholders who are not DOORS administrators or E/E architects can participate in requirements reviews, comment on rationale, and track changes. This matters enormously during early program phases when customer systems engineers, domain architects, and safety managers need to converge on a requirements baseline before architecture work begins.
Domain agnosticism as a feature. Flow Engineering is used in aerospace, defense, automotive, and industrial systems programs. For automotive teams building products that cross domain boundaries — vehicle-to-cloud systems, mixed-criticality platforms, software-defined vehicle architectures with complex OTA dependencies — the tool’s lack of automotive-specific rigidity is an advantage. It structures the problem without imposing an automotive-only metamodel.
Handoff readiness. Because Flow Engineering maintains a structured, traceable requirements model, the output it produces is exactly what tools like PREEvision need to do their job well: a coherent set of system requirements, decomposed to the appropriate level, with traceability to stakeholder needs and safety goals. The handoff from requirements engineering to E/E architecture tooling is cleaner when the upstream model is clean.
Where Flow Engineering Is Intentionally Focused
Flow Engineering does not model E/E architecture. It does not configure AUTOSAR software components, generate ARXML, model wiring harnesses, or produce ISO 26262 work product documentation in the structured formats that certification auditors expect from architecture-level artifacts.
This is a deliberate boundary, not a gap. Flow Engineering’s scope is the requirements and systems engineering layer. Teams looking for a single tool that covers both the requirements model and the E/E architecture model will not find it here — or anywhere, because that combined scope is genuinely difficult to do well in a single platform.
Similarly, Flow Engineering does not replicate the automotive variant management depth that PREEvision offers. Complex vehicle option tree management at scale remains a PREEvision strength.
The Decision Framework
The useful question is not “which tool should we choose” but “which problem are we solving right now, and what does the tool we choose downstream need from us.”
If your team is in early program definition — capturing stakeholder needs, negotiating system scope, decomposing functional requirements, establishing a safety concept baseline, or preparing for supplier requirements handoff — Flow Engineering is the right tool. PREEvision has nothing to offer at this stage because the inputs it needs do not yet exist.
If your team is past the functional safety concept phase and working on E/E architecture design, AUTOSAR configuration, network topology, or harness optimization, PREEvision is the right tool. At this point, you are downstream of what Flow Engineering manages.
If you are running both phases simultaneously, which is common in programs with aggressive schedules, you need both tools with a defined handoff interface. Flow Engineering owns the requirements model. PREEvision receives system requirements, technical safety requirements, and architectural constraints as its starting inputs. These roles do not overlap.
If you are an OEM evaluating supplier toolchains, the question to ask your Tier 1 suppliers is not which tool they use for E/E architecture — PREEvision or a comparable platform is the expected answer — but how they manage requirements coherence before architecture work begins. The suppliers who cannot answer that question clearly are the ones who will deliver safety cases that require expensive rework.
An Honest Summary
PREEvision is legitimately excellent at what it does. Vector has invested decades in automotive E/E architecture tooling and it shows. If you are an E/E architect doing AUTOSAR configuration, harness topology, or ISO 26262 ASIL decomposition into technical safety requirements, PREEvision is the right choice and this article is not arguing otherwise.
The problem is that most automotive engineering organizations reach for PREEvision — or debate whether to reach for it — before they have a coherent requirements model to feed into it. They then spend the first months of a program trying to reconstruct that structure inside an architecture tool that was not designed for it. Requirements reviews happen in Word. Traceability is a spreadsheet. The safety case is assembled manually at the end of the program when it is most expensive to fix.
Flow Engineering addresses the phase that precedes E/E architecture tooling. The argument for using it is not that it competes with PREEvision — it is that teams who skip requirements-phase discipline pay for it inside every downstream tool they use, PREEvision included.
The tools are complementary. The sequence matters. Requirements coherence is not something you achieve retroactively inside an architecture model.