Your EGSE Is the First Component to Read Your ICD
The electrical ground support equipment is the first thing on your program to implement your interface control document, and the last thing anyone verifies. An engineer reads the supplier's ICD, builds a checkout rack against that reading, and for the length of the assembly, integration and test campaign their reading is what "correct" means on your floor. You are not testing the flight unit against the ICD. You are testing it against one person's interpretation of a PDF.
Walk onto a satellite AIT floor and the ground equipment outnumbers the spacecraft. An overall checkout system drives the campaign, and behind it sits a rack of special checkout equipment: a power SCOE, an RF SCOE, a payload SCOE, each one the front end between the checkout system and a piece of flight hardware. They speak MIL-STD-1553B, SpaceWire, CAN. They pack and unpack CCSDS packets against a mission database. By any working definition, they are components that talk to your spacecraft.
Your program has an ICD for the reaction wheel, an ICD for the star tracker, an ICD for the transponder. It has a purchase order for the SCOE.
The equipment we trust most gets the least rigor
On 6 September 2003, at Lockheed Martin in Sunnyvale, a team rotated the assembled NOAA-N Prime satellite from vertical to horizontal on a turn-over cart. It slid off and hit the floor. The mishap investigation board found that the adapter ring was not bolted to the cart: another project had removed the 24 bolts while the cart sat in a common staging area, and had not told the NOAA team. Repairs ran to $135 million, and the satellite did not fly until 2009. The board's language about the operations team is worth reading twice: complacency toward routine spacecraft handling, poor communication and coordination, and poorly written procedures.
That is mechanical ground equipment, and we are not going to pretend a SCOE can drop a satellite. The institutional habit is what carries over. The cart was not anyone's flight hardware, so it belonged to no project, so no one checked its configuration before trusting a spacecraft to it. Your SCOE sits in the same category. It is not flight hardware, so no one puts its interface under configuration control, and no one checks its reading of the ICD before you trust a full test campaign to it.
Your SCOE outvotes your ICD
During AIT, the SCOE is the thing in the room. When the flight unit and the SCOE disagree about a field, someone decides which one is wrong, and the SCOE arrives at that meeting with months of passing tests behind it. The unit arrives with an anomaly report. The unit loses.
Sometimes the unit deserves to lose. Sometimes the SCOE author misread a scale factor, assumed big-endian where the supplier meant little-endian, or coded a telecommand acceptance window more forgiving than the real one. Then your team tunes the flight unit until it matches the SCOE, closes the anomaly, and moves on. You have built the misreading into the spacecraft. The ICD still says what it always said. The two of them will not meet again until the neighbor component arrives, built by a different vendor who read the same document and got a different answer.
When the flight unit and the SCOE disagree, the SCOE usually wins. It has months of green tests behind it, and it is the one in the room.
Building the SCOE is a free ICD review, and you throw it away
Someone had to build that SCOE from the ICD alone. That is the first executable test your interface document ever faces. If they built it without calling the supplier, your ICD is complete enough to implement. If they called, the call was a finding.
Those calls happen on every program we have worked on. What is the byte order on this field? Does this counter wrap or saturate? Is the timestamp the sample time or the transmit time? What does the unit send when it has no valid measurement? Each question is an interface defect caught months before integration, by the cheapest means available, by the first person who tried to write code against the document. The supplier answers by email, and the answer stays in that thread.
Three answers, none of them in the ICD, all of them now load-bearing in your test equipment. The next reader asks the same three questions. If the next reader works for the neighbor vendor rather than for you, they may not ask at all. They will guess, and their guess will be reasonable, and it will be different.
Generating the SCOE buys you one error class, not two
If your interface lives in a schema rather than a document, generate the SCOE from it: the packing and unpacking code, the limits, the command dictionary. That removes the transcription errors. No engineer retypes a scale factor from a table into C, so no engineer fat-fingers it.
We have argued before that a simulator generated from the same model as the flight code proves nothing, and the caution applies here too. A generated SCOE and a generated flight driver share a parent. If the schema has endianness wrong, both get it wrong, both agree, and the tests stay green. Generation buys you agreement between the SCOE and the interface definition. It does not buy you a correct interface definition.
Use the generated SCOE for what it proves, which is that your side is self-consistent. Then keep the one thing that can contradict the schema: the supplier's real unit, on a bench, as early as you can get one. The disagreement is the data you were after.
Treat the SCOE as a component and the rest follows. It gets an interface definition instead of a purchase order. It gets a version, and the test report records which version ran, so that a result from March means something in September. The questions its author asked go back into the interface rather than into an inbox. When the SCOE and the flight unit disagree, you have a document that settles it, instead of a vote between two things that might both be wrong.
The bolts came out of that cart because the cart was not anybody's spacecraft. Your SCOE is not anybody's spacecraft either. It is the thing with its hands on the flight unit for the months before launch, and on the day it disagrees with your ICD, it wins. Write the SCOE an ICD, or accept that it has already written one for you.
