How to Choose an On-Board Computer Development Company: What to Check Before You Outsource

Check that the supplier has delivered a qualified on-board computer for a comparable platform; that one team carries the board, FPGA logic, enclosure and qualification, so you are not integrating subcontractors; and that IP, design files and test reports transfer to you. InTechHouse delivered the complete hardware of Latitude's on-board computer for the Zephyr launch vehicle, through environmental qualification; Latitude's own team wrote the flight software.

Key takeaways

• Choose an on-board computer development company you can trust with the whole project first; technology comes second.
• Ask which parts the supplier subcontracts. If the board, FPGA logic and enclosure come from different companies, the integration lands on you.
• A working prototype is not the goal. Look for a supplier that brings the unit to a tested, qualified state and can name the standards and laboratories.
• Ask for evidence: a named reference, the qualification status in the client's own words, and what is still ahead.
• Make sure intellectual property, design files and test reports transfer to you, because the computer will outlive the contract.

When outsourcing on-board computer development makes sense

Outsourcing makes sense when your team is missing one competence the on-board computer needs. Most teams do not hand over a whole product. They commission a slice of the project, and the trigger is usually a gap: hardware, FPGA logic, or qualification experience.

An on-board computer (OBC, also written onboard computer) is the central processing unit of an uncrewed vehicle, such as a launcher or spacecraft. It collects sensor data, runs sequencing or control software and communicates with the ground.

Latitude, the European launch vehicle manufacturer building the Zephyr rocket, is a clear example. Latitude's team was strong in software, and the hardware is what they brought to us. Their engineers kept the flight software, and we delivered the hardware platform, FPGA IP cores and the path through qualification. The integration between the two was defined by that split from the start.

Hire or outsource? Hire when the competence is core to your product and you will need it on every program that follows. Outsource when the need is specific to one project, or when building the team would take longer than the project itself. Many New Space companies do both: they keep software in-house and buy custom on-board computer design services for the hardware.

Define what your on-board computer must do before you ask for quotes

A supplier can only quote what you specify. Before you contact any on-board computer development company, write down the key features your mission needs. This list is a starting point for most space missions and other mission critical applications:

• Computational capability and memory resources. How much on board processing happens in the vehicle, and how much memory and storage the software needs, with margin for functions added later.
• Data handling system. Which sensors feed the computer, at what rates, and how data is packetized, stored and passed to the ground.
• Communication systems. Which radios, buses and vehicle interfaces the computer talks to, and what telemetry you need to monitor the health of the vehicle during operation.
• Fault tolerance and fault recovery. What must happen when a component fails or the processor resets, and whether you need a fault tolerant architecture with redundancy, watchdogs or safe modes.
• Autonomous operation. What the computer must decide on its own when there is no ground contact, including recovery from faults without an operator.
• Power consumption, compact form factor and robust design. The power budget, the space and mass available, and the environment the computer has to survive.
• Security. How firmware updates are authenticated and protected against tampering.

High performance on paper matters less than a solution that delivers these functions within your power and mass limits. A good supplier will answer this list candidly, including telling you when an off-the-shelf computer already has the capabilities you need.

Criterion 1: A partner you can trust with the whole project

Start with trust and responsibility, then look at technology. That is the order our own Vice CTO applies when he is the one buying.

"I'd look for a company I can trust with a project like this: one that will do it end to end and take responsibility, and bring the product to the point where it's not only designed and working, but tested."

‍

Adam Szychulec, Vice CTO, InTechHouse

Once trust is in place, check three things:

• The competence of the people who will work on your project, not only the company's portfolio.
• Similar projects delivered, ideally in high reliability work for mission critical applications.
• Testing experience, because a board that works on the bench is a different thing from a board that has passed qualification.

"End to end" is what you should be able to get, not what every engagement has to be. A good supplier can take the whole project, and can also take the slice you are missing without forcing the rest on you.

Criterion 2: One team for the board, FPGA logic and enclosure

When the board, the FPGA logic and the enclosure come from different subcontractors, someone has to integrate them afterwards, and that someone is usually you.

"When different parts go to different subcontractors, someone has to integrate them afterwards. Give the board, the software and the enclosure to one supplier and you don't have to make three subcontractors talk to each other. That happens inside."

‍

Adam Szychulec, Vice CTO, InTechHouse

The interfaces between those parts are where problems hide. The FPGA fabric depends on the board layout, the board depends on how the enclosure fixes and cools it, and all three have to pass the same tests together.

Put one control question to every candidate: which parts do you subcontract, and who integrates them?

Then ask how prototypes are used. A single team can plan quick iterations that verify the hardware and software together, so integration problems surface on the bench rather than in qualification.

The enclosure belongs in that scope. It is not a box bought at the end. It is designed for the tests and for vibration, alongside the electronics, as we explain in our article on launch vehicle electronics design.

Criterion 3: A unit brought to a tested, qualified state

A credible supplier runs testing in two layers. First comes pre-compliance in-house, where problems are found on the supplier's own bench. Then come formal tests in accredited laboratories, under the supplier's responsibility. The output is a report set your team uses for its declaration of conformity.

On Latitude, InTechHouse ran EMC pre-compliance testing in-house and was responsible for the tests in accredited laboratories. The on-board computer went through a customer-specified test regime: EMC to MIL-STD-461G and environmental testing to MIL-STD-810, both tailored with ECSS-derived requirements.

What to ask:

• Which standards has the team actually tested to? A list of standards a supplier "supports" is not the same as a list it has taken hardware through.
• Which laboratories were used, and who was responsible for the campaign?
• Which test facilities can the supplier reach? For space applications, ask about thermal vacuum chambers, vibration testing and, if your program requires it, HALT.
• What happens when a test fails? Ask how the supplier handles fault detection, root-cause analysis and redesign before a retest.
• Does your program require DO-254 or DO-178C? If so, ask the supplier directly whether they have delivered under them.

Watch the wording. Engineering suppliers do not certify products; accredited laboratories and notified bodies do. A supplier that says "we certify" is either using the word loosely or overstating its role. The full sequence is covered in our guide to on-board computer qualification.

Criterion 4: Comparable platforms already delivered

The strongest evidence is a client describing the result in their own words. This is what Latitude says about the on-board computer we built for their launch vehicle:

"We've worked for almost three years with InTechHouse and it became a successful partnership along the years with the delivery of a fully qualified On-Board Computer for space vehicle. It started with software and hardware development, then casing and PCB routing and finally an environmental qualification. Some steps were harder than others like any electronics project but the team was always available, efficient and professional. The success of this first journey allow us to think about our future avionics developments with InTechHouse."

‍

Valentin Belaud, Head of Electrical & Software Systems Department, Latitude

When you assess any on-board computer supplier, ask for the same kind of proof:

• A named reference you can contact, not an anonymous logo.
• The qualification status in the client's words, for example "fully qualified", rather than the supplier's marketing phrase.
• What is still ahead. A unit can be fully qualified and still not have flown. Zephyr's flight testing is next, and an honest supplier will tell you where each project stands.

Read the full Latitude on-board computer case study.

What the Latitude scope included, and what it did not

InTechHouse case study: Latitude on-board computer

Included:

• the complete hardware of the on-board computer
• an enclosure designed for testing and vibration
• FPGA IP cores for time and frequency synchronization
• design suggestions for the wiring harness
• qualification: pre-compliance in-house and responsibility for tests in accredited laboratories

Not included: the flight software and flight control, including data handling logic at mission level. Latitude's own team wrote them.

Status: fully qualified, in the client's words. Flight testing is next, InTechHouse is now producing flight models, and the cooperation continues.

That boundary is worth knowing before you talk to us. If you have a software team and need the hardware, this is the configuration we have already delivered.

Criterion 5: IP, design files and test reports transfer to you

Here "IP" means intellectual property, not an FPGA IP core (a reusable logic block). Ask every shortlisted supplier whether the intellectual property, the full design files and the test reports transfer to you at the end of the project.

This matters because an on-board computer stays in service for years, often longer than the components inside it stay in production. Over that time, components go end-of-life, suppliers change, and you may need to re-manufacture a batch or re-source a part. Without the design files you cannot do either, and you remain dependent on the original supplier for every change.

At InTechHouse, the IP and the full documentation go to the client, including the design files and the test reports. For the wider ownership argument, see our comparison of custom vs COTS on-board computer options.

If the core of your on-board computer is an FPGA

When the architecture is FPGA-heavy, the supplier also needs RTL design and IP core experience, not only board-level skills. On Latitude, the FPGA fabric carried IP cores for time and frequency synchronization, which is the kind of work to ask a candidate about. For that part of the evaluation, use our dedicated checklist on how to choose an FPGA design company.

Questions to put to every shortlisted supplier

These questions apply to any embedded computer design partner. The answers differ by project, so ask them in writing and compare:

• Who owns the IP, design files and test reports at the end of the project?
• How are changes controlled and priced once the requirements are agreed, and how is cost tracked against the estimate?
• How are fault tolerance and fault recovery verified, not only designed?
• How is the firmware protected against tampering, and is security part of the design review?
• What does acceptance testing look like, and who defines the pass criteria?
• Which standards has the team tested to, and in which laboratories?
• How are component obsolescence and counterfeit risk handled in sourcing?
• Which parts are subcontracted, and who integrates them?
• How will power consumption be budgeted and verified against your power supply limits?
• How is data integrity protected between the processor, the FPGA and the vehicle interfaces?
• Does the design assume a real-time operating system (RTOS), and who owns the board support package your software team will build on?

Supplier checklist before you sign