The 'Model Philosophy' Used by Space Engineering Companies

In my day job, I have the privilege of being the head of electronic design for Astrium Products Payloads in the UK. Primarily, we develop telecommunication processors for telecommunication satellites. Not surprisingly, these satellites require the very highest levels of reliability and use very high-grade components. We also implement complex redundancy architectures and perform extreme amounts of design analysis.

The components we use can be very expensive -- many tens of thousands of dollars for a one-time programmable (OTP) FPGA, for example. It is therefore crucial that we have a staged development schedule that retires risk as it progresses, ultimately resulting in a space-qualified product.

In fact, the way we do this is pretty much standard across most space engineering companies. The development is split into numerous phases, which we refer to as the "model philosophy." The most commonly used flow is as follows:

Engineering Bread Board (EBB): This is the initial prototype and is only functionally representative of the final module. This allows the more complicated packaging design to be taken into account in the next phase. This EBB will use commercial components and will hopefully be the least expensive of the models. This model will employ, for example, commercial reprogrammable FPGAs as opposed to OTP space-grade FPGAs. Not surprisingly, this is the model that may well experience a number of revisions until the function is finally as required.

Engineering Model (EM): This model is form, fit, and functionally the same as the final flight model; however, it will use a mixture of flight-grade components (usually spare or out-of-life in stores) and commercial components.

Engineering Qualification Model (EQM): This is the model that is subjected to the qualification campaign. This usually includes design updates from the EM and uses identical components to flight; however, these components do not need to be screened to the flight standard.

Proto Flight Model: This is a flight model that is subjected to the same qualification levels as the EQM. Sometimes, for cost issues, this is also flown.

Flight Model: The models actually flying; these are tested to acceptance-level testing.

From this...

...to this...

...to this!

The ability to prototype in the lab -- be it testing a custom-designed PCB specifically for a task (EBB in the above philosophy) or a "lash-up" consisting of vero-boards and an engineer's attempt at soldering -- allows one to quickly determine whether a concept is viable... or not.

This is especially true when working with complex systems. Although modelling tools do provide a good indication of how the product should perform, there really is no substitute for getting hardware in the lab early and then learning on the hardware. This allows engineers to demonstrate to the customer and internal management that the required performance can be achieved. At the same time, with careful planning, it allows some risks to be retired early.

Of course, the prototype is just the start of the journey. You will have a number of design analyses and -- I am reasonably confident -- a re-spin or two of the board as you progress towards the final qualification of your product. This will have all started on your bench in the lab, which may seem a distant memory by the time you get to deliver the system.

How do you prototype products in your field? Do you even prototype, or do you use a version of the "suck it and see" approach?

@kfield, The operational life is 15 years the additional 2 years is for the testing and qualification campaign on the satellite and any storage while it awaits the launcher being available.

Last week the most advanced telecommunications satellite ever was launched, the payload processor (the heart of the system and what makes it so advanced) was developed my group here in the UK, this took up a large portion of my life over the last few years. I have a blog for Max on it just getting approval so hopefully next few days or so and he should have it.

I completely agree in that building real models is essential in order to reduce costs when a hardware design is going to be implemented.

Of course, in the vertical markets I use to work, reliability requirements are no so strict as yours; in this way, I usually jump from bread-board --or dev-kit plus breadboard-- prototype to pre-series production...

It is a big challenge as both the non recurring cost and recurring cost need to be controlled. But as you say quality is key, we do find we try to do a lot of bom rationalisation accross the design and if possible other projects to. There is also alot of justification as to is that component really needed.

Hi Adam: Thanks for posting this. It's certainly interesting to see how a prototyping strategy shifts when you are dealing with very expensive products. I recently participated in a team building exercise where we were challenged to build an "egg protection device" using only plastic straws, duct tape, and balloons. Each team had to "purchase" supplies (our attempt to buy up the entire inventory of straws didn't fly) to make their protection device. Under the rules of engagement, if more than one egg in its protective shroud survived the drop off a ten-foot ladder, the team with the lowest BOM would be declared the winner. It turned out that our team had the only surviving egg--and the highest BOM of all! That's because we opted for a srategy of "screw the cost, we need to get something out there that works". I'm wondering if other readers identify with this approach? Or iis it a ridiculous strategy that only works when the money you are dealing with is play money?

I am not from "space telecom/satellite industry" but to some extent understand the rigor behind multiple phases of prototyping, reliability calculation, testing as the equipments you design can't afford to have a failure causing loss of function and can't afford to come back for a "repair or replacement" :). It is pretty interesting to know the 'Model Philosophy' behind your job.

I am from the industrial background and the design philosophy differs a bit. Money is a factor here and also time to market. Hence things are done in shorter time, spending less on numbers of prototype passes but certainly not compromising with the "needed" quality. Again, there are certain applications such as "Functional Safety" where the failure of a system could cause hazard to human lives or loss of properties...there we also practice similar kinds of rigor...we do HAZOP, FMEDA etc. to calculate probability of failures and follow standards (such as IEC 61508) to avoid "systematic faults", design necessary diagnostics or build redundancies to maintain required "Safety Integrity Level"...also we need to go through assessment by independent agencies (as TUV) and approvals. You might have heard about Functional Safety (IEC 61508).

As you say you have to ensure you can with stand failure and have the reliability architecture to enable your mission goals. This is where the Failure Modes Effects and Criticality Analysis is very important as it allows you to determine the effect on the system of a component failure.
Typically our systems have to function for 17 years with very little down time as a telecommunications satellite is a business. This means you need a high probability of success which is determined by the FIT rate after FMECA and reliability architecture.
Should I write more about this area ?

The steps represent what any highly-available/reliable system has to go through. After 30 years designing/implementing software that runs major manufacturing plants that has to

1. tolerate any single component failure (hardware/software/network).

2. tolerate multiple failures at multiple levels

3. run on a 365x24 basis (6-sigma is not good enough)

I understand something of this. Part of the process is also planning for failure. :-) So, I'd like to see some treatment of this issue. Planning and designing for reliability is one thing, but if you don't also plan for / design for inevitable component failures (components being hardware, software, or engironmental) then you are only 1/2 the way there... :-)