Arc supports ECSS-governed engineering by connecting requirements, systems, verification activities, evidence and review context in a flexible project model. Its ECSS project templates help teams get started, and its ECSS compliance agents propose edits for engineer review. Evaluate the software against your actual contract workflow: the project remains responsible for applicability, engineering execution and the justification of its compliance claims.
What are you buying ECSS compliance software to improve?
A supplier approaching its first contract may need to reduce the effort of keeping commitments and engineering work consistent. Consider a requirement that appears in the tender response, is copied into a specification, acquires a verification method and later depends on a report. When the requirement changes, the team needs to understand which statements and evidence still apply.
Define the buying job before the demonstration. Perhaps engineers cannot identify the current requirement revision, the project manager cannot see which evidence remains outstanding, or supplier updates require manual reconstruction of relationships. Choose one problem that matters to the next contract milestone and test whether the proposed workflow makes it easier to resolve.
A compliance label alone is a poor selection criterion. ECSS-S-ST-00C Rev.2, clauses 6 and 9.3 places the requirements in the customer-supplier agreement and makes the supplier responsible for demonstrating compliance. Software can organise and support that work; a product name does not establish that the delivered engineering fulfils the agreement.
How Arc connects the engineering information
Arc's connected engineering model links requirements with the systems responsible for satisfying them, the associated verification activities, supporting evidence and review context. The model is flexible enough to organise project information around the engineering process. Teams should configure relationships and record meanings so the connections answer useful questions.
| Information to connect | Question it should help answer | What to inspect in an evaluation |
|---|---|---|
| Requirement and source | Where did this obligation come from? | Source identity, revision and the meaning of the relationship |
| Requirement and responsible system | Where does the engineering response belong? | Allocation, ownership and lower-level context |
| Requirement and planned activity | How will the team demonstrate fulfilment? | Verification purpose and the relevant planning information |
| Activity and evidence | What information supports the current conclusion? | Evidence identity, conditions and represented configuration |
| Records and decision | What has been agreed, and what remains open? | Reviewed material, rationale and follow-up responsibility |
The evaluation questions are recommendations, not a claim that every listed field is present in a default project. Ask how the actual Arc configuration represents the information your customer needs. This keeps a product demonstration anchored to a usable engineering process.
Represent applicable clauses without turning every clause into hardware
A project needs to distinguish an applicable ECSS obligation from the product requirements derived or received for the design. Some obligations concern engineering activities, procedures or deliverables. In the supplier's compliance response, those should connect to the work that addresses them. A clause about verification planning does not become a numerical pointing-performance limit.
The customer and supplier requirements in clauses 9.2 and 9.3 provide the source distinction: applicable requirements are identified in the project documentation, and the supplier documents its compliance position. Arc's configurable records and relationships provide a way to organise that project mapping beside the engineering model.
During evaluation, bring one product requirement and one process obligation. Ask the team to show how each connects to its fulfilment path. If both are forced into a single undifferentiated list, consider whether that arrangement will make ownership and evidence harder to understand. Use the ECSS compliance matrix example to prepare the questions.
Worked evaluation: follow the Lark requirement
The fictional Lark attitude-control unit gives the evaluation a concrete thread. REQ-LARK-010 specifies maximum steady-state pointing error of 0.15 degrees. An existing analysis reports 0.12 degrees under stated assumptions. These teaching values are not ECSS limits, a complete spacecraft requirement or an Arc customer result.
Start by asking an engineer to find the source requirement and explain its scope. Follow the relationship to the responsible engineering work and analysis report. Then ask the verification owner what else must be known before the report supports close-out. The numerical result is below the threshold, but the operating conditions and represented configuration still matter.
Next introduce the proposed 0.10-degree limit. The recorded 0.12-degree result now exceeds the proposed threshold. Ask how the team preserves the original requirement and report, records the proposed change and investigates its effects. The illustrative Lark programme records let each participant examine the same small scenario.
The goal is not to obtain a favourable product verdict from a prepared example. It is to discover whether the team can reconstruct the engineering reasoning, identify missing information and reach the next decision without rebuilding the story in a separate presentation.
Support the VCD information and the change process
ECSS-E-ST-10-02C Rev.1, Annex B describes the VCD's planning, evidence and close-out information. ECSS-M-ST-40C Rev.1, clause 5.3.2 describes controlled change assessment and disposition. These are useful references for choosing the workflows to examine with your team.
Arc connects verification information and supports branches, revisions and baselines. That can help a project organise its current engineering state and proposed changes. The team still establishes the required review process, confirms evidence applicability and decides the necessary follow-up.
Ask how the configuration will capture your required VCD information and how the customer will receive the agreed deliverables. Confirm the actual output format and exchange behaviour during the evaluation. This article does not assert a particular prescribed export or that a connected report automatically satisfies a customer's document requirements.
What the ECSS templates and agents add
Arc offers ECSS project templates to help establish a starting structure. Adapt that structure to the supplier scope and contract rather than assuming it determines applicability. The useful setup outcome is a project that makes obligations, planned work and unresolved decisions understandable to its engineers.
Arc's ECSS compliance agents work across relevant clauses and propose edits for engineer review. Evaluate their actual findings against a bounded set of project records. Inspect the technical meaning of a proposed change and the information it relies on before deciding whether it helps.
The templates and agents address different parts of adoption. A template helps you start organising the work; an agent provides assistance with a defined review task. Neither eliminates the need to understand the obligation being addressed. The project-template setup guide and agent review guide cover those tasks separately.
Run a pilot that can reveal a poor fit
Choose a contained but representative requirement set. Include an open verification activity, an existing report, a process obligation and a proposed change. Give each participant a task they would perform on the project. Record where they need extra explanation, where information is missing and where the configuration needs improvement.
| Pilot task | Useful evidence from the exercise |
|---|---|
| Trace a requirement | The engineer can identify its source, current revision and responsible work |
| Assess a report | The reviewer can explain what the evidence supports and what remains uncertain |
| Review a proposed change | The team can distinguish the baseline, proposal, decision and follow-up |
| Inspect an agent suggestion | The engineer can evaluate the proposed edit and record a reasoned response |
| Prepare customer information | The team understands what it can provide and what configuration or work remains |
Include difficult examples, not only complete records. A report for another configuration or an obligation with an unresolved applicability decision can reveal whether the workflow communicates uncertainty clearly. Measure the effort to reach the engineering decision, not merely the speed with which a document appears.
Make the buying decision against the project
Compare the pilot results with your original problem. Has the team made source, ownership, evidence or change questions easier to answer? What setup work remains? Are the required customer exchanges and approval arrangements workable in the intended configuration? Record any material gap instead of allowing an impressive demonstration to substitute for the missing assessment.
For a first ECSS-governed contract, Arc's relevant proposition is a connected place to organise engineering obligations and evidence, supported by templates and agent proposals. The decision should turn on whether that approach helps your engineers maintain an understandable compliance position as the work changes.
Bring the actual scope, a representative requirement and an evidence example to the evaluation. Keep the first goal concrete: show how your team will move from an agreed obligation to the work, evidence and decision needed to address it.
Frequently asked questions
Is Arc ECSS compliance software?
Arc supports ECSS-governed engineering workflows by connecting requirements, systems, verification activities, evidence and review context. It also offers ECSS project templates and agents that propose edits for review. The project remains responsible for its applicability decisions and compliance demonstration.
Does using Arc guarantee ECSS compliance?
No. ECSS-S-ST-00C Rev.2 assigns the supplier responsibility for demonstrating compliance with the applicable project requirements. Arc can support the organisation of that work; the actual engineering, evidence and required decisions still need to be completed.
How does Arc help a first-time space supplier?
Arc provides a flexible model for connecting obligations, requirements, engineering work and evidence. ECSS templates offer a starting structure, while ECSS agents propose edits for engineer review. A useful evaluation follows one representative requirement through the intended project workflow.
Can Arc produce every required ECSS document automatically?
This guide does not claim automatic production of every ECSS deliverable. Define the content and format required by your customer, map the necessary information to the project configuration and confirm the actual output and exchange capabilities during evaluation.
What should an ECSS software evaluation include?
Use a representative requirement set, an applicable process obligation, an evidence report and a proposed change. Ask engineers to examine traceability, evidence applicability, review decisions and any agent suggestions, then record the remaining configuration and delivery gaps.
Evaluate Arc
Bring your ECSS requirements, reviews and evidence together.
Evaluate a complete ECSS workflow on a representative part of your programme. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.