Death by Standards
You start a new job in space as a Systems Engineer. You are full of dreams and hopes, and you want to really, really make a dent in this blooming industry. The company you work for is an early stage startup at early stages of development trying to design a spacecraft of some kind. As your design matures, you find yourself leading the overall development and you need to front reviews. Reviews include, no surprise there, reviewers. One fine day, this reviewer asks a question that will shape your career for the next decades to come:
— Do you comply with the [insert_quasi_random_sequence_of_numbers_and_letters] standard?
You think: geez. Do I? You don’t know. Maybe? You google it nervously. It’s a 170-page document written in the most not-to-the-point style ever. What a boring-looking, anodyne piece of writing, you think. While skimming through it, you see there are some things you kinda do comply with, while others, well, not really. One thing is clear: you are not reading those 170 pages from cover to cover anytime soon: you hop from the index to certain sections that capture your attention, only to go back to the table of contents and stop at some figures. You happen to observe that the document points to many other similar-looking document codes, so out of curiosity you go to check what other standards this organization has published: lots of them.
By the way, the reviewer is still waiting for an answer. You decide to answer something you learned from a veteran Systems Engineer time ago: you comply but in a “tailored” way. Clever.
As it happens, because your satellite under design must send data back and forth to earth using data links, and you must ensure those data links are compatible with stations sitting on the ground, there you are again dealing with standards. Another acronym pops up: CCSDS. You google it. It seems to be an organization that manages the definition of standards for communicating with satellites by means of noisy radio links. You feel optimistic, maybe this CCSDS folks keep things lean, and rather small. You hope they are a “less is more” kind of organization. Think again. As you visit their website, another tidal wave of documents hits you, this time color-coded:
Blue: Recommended Standards
Magenta: Recommended Practices
Green: Informational Reports
Orange: Experimental
Yellow: Record
Silver: Historical
Protocols, frames, ARQ, primitives, primary headers, secondary headers, PUS services, cryptography, checksums, and what have you. After a while, your head is full of the jargon. All with the necessary dose of circular references when one document makes you go and look to some other document only to find the same but in the opposite direction. How many documents of each color are there, anyway? Hard to say; the page at CCSDS is throwing an error at the moment, which is quite undescriptive1:
A thought that quickly comes to your mind and the minds of anyone having to go through the pain of surfing standards: standardization organizations, ironically, do not seem to talk to each other. There’s a lack of standardization of the standardization. For instance, take the ECSS-E-ST-50-03C (“Space data links - Telemetry transfer frame protocol”) along with the CCSDS 132.0‐B‐1 (“TM SPACE DATA LINK PROTOCOL”). Don’t they, like, tackle the exact same thing? They do. Why have two standards? The confusion is so real, that the former has an Appendix explicitly added to point out the differences with the latter:
You gotta love this. Appendices written to clarify how standard X is different from standard Y. How about picking up a phone and deciding to keep only one? No; real bureaucrats do not retire documents so easily. Mind you, the differences are infinitesimal. Not sure who plagiarized who here, though. And to finalize with some more bewilderment with the CCSDS body of knowledge, a special word about the somewhat casual recommended adjective in front of the word “standard”. CCSDS are mere “suggestions”, and not everybody gets this. How much you want to implement from a CCSDS standard is up to you. When you read that something is CCSDS-compliant you better check what is the coverage of the recommended standards, as it may very well be opportunistically small.
Alright, so, back to your work as a Systems Engineer after digesting radio link standards. Now you need to discuss with your avionics engineers a few things related to how the data inside the spacecraft will flow. You like Ethernet; everybody does. Who doesn’t like Ethernet? It’s ubiquitous and straightforward. It does the job. So why not adopt it across your architecture? If you wanna use Ethernet across the electronics you design, you better understand the specification well, because those frames will have to traverse across multiple physical layers like printed circuit boards, backplanes and cables, so you better make the right moves. Then, you need to go to the sources and take a look at the world-famous IEEE 802.3. How? Easy. First pay to get the doc, and then ingest its 7000 pages. Sure, sure; most likely you do not need to read each one of those pages, but at least you need to look around to identify the sections that matter for your issue at hand (for instance, the section that tackles Ethernet on a backplane, covered in Clause 70).
Quite probably you will combine Ethernet with other serial interconnects, for instance, PCI Express. Need to get the gist on how to implement PCIe in your system? You and your team will have to enjoy 60 or 70 different specifications that are waiting for you.
Everybody is modular today. It’s rather cool to be modular than non modular. But to be truly modular, you gotta embrace standards, otherwise you’re just creating your own little weird universe. For pursuing modular and standard form factor electronics, you most likely will need to browse through something like VITA’s approximately 100 standards that tackle backplane-based electronics systems if you pretend to comply with signal routing, pinout, connectors, reliability and signal integrity matters in a way you can use VITA-compliant components in your design. But wait: wasn’t reliability tackled by the ECSS soup of standards? Yes it was, but because there is no semantic connection whatsoever between these organizations, they cover the same topics over and over in different standards. If you wanna read about reliability in electronics, you may either pick and buy VITA 51 standard, or maybe you go low-cost and use ECSS-Q-HB-60-02A. Your choice, but pick wisely. Sure, ECSS is for space, whereas VITA is for other applications (military, industrial) as well, there might be reasons why they duplicate work. Still, couldn’t they, like, consolidate standards for the sake of our sanity?
And now that we are into topics like designing electronics in-house, then you better keep an eye on the IPC standards of course, which will specify things from how you need to assign footprints for surface-mount components in a PCB to how to fold a through-hole resistor leads with a plier or manually solder a capacitor. Just 300 standards; easy peasy.
The growing complexity of the underlying devices used at the board level does not make it simpler. Ok, this is not a standardization issue per se, but worth mentioning that for most System-on-chips out there, there is a Technical Reference Manual with at least 1000-pages waiting to be read. And because said SoC surely happens to use a licensed CPU core, most likely the reference manual for the core is another thousand pages easter egg. For instance, go check the Zynq Ultrascale+ TRM (1200 pages), which happens to use an ARM processor. If for a crazy moment you were thinking of coding an emulator of that core yourself, you just need to go see the “Arm Architecture Reference Manual for A-profile architecture” document and its 13000 pages to reconsider your life choices. Only opening that document will melt your laptop.
And, if in the last twist of your bad luck, your spacecraft has anything to do with 5G, then you’re finally cooked. If you happen to be working on some direct-to-device service or non-terrestrial IoT application using 5G, I pray for your soul. Sure thing: 5G is pure marvelous engineering genius resulted from majestic consensus. The fact that 5G can ensure stable, reasonably fast data communication to a myriad of moving nodes in a wide area, from humans to low-power sensors across multiple base stations is truly mesmerizing. But that functionality comes with its dose of sky-high complexity. By some accounts, there might be more than 100,000 pages worth of specifications by the 3GPP to describe 5G. The 3GPP TS 23.501 alone (the 5G core network architecture definition document) is a 700 pages long Word document that will leave your Office application crying for more RAM.
If your project includes any software, what are “the standards” to stick to if you wanna be cool? It could be ISO/IEC 12207, which specifies life cycle models, terminology and criticality levels, you could also consider ISO/IEC 15504 or it could be the more celebrated DO-178C from RTCA if you are feeling a tad more aerospace-y.
But why not doing software as per ECSS-E-ST-40C? It’s a software standard as well, a strong contender, and a cheaper document. And what about the maturity levels? Remember those? They were very popular 15 years ago. Time flies. And, oh boy if you’re doing anything related to protocols and Internet and you need to get close to the Internet Engineering Task Force and its more than 9,000 technical standards written in plain text.
And how about in the Systems Engineering domain? How do you perform Systems Engineering “by the book”? Do you do it as per ISO 15288 or perhaps you feel a bit more “SME” and you do it as per ISO 29110 which also includes software stuff in it so you could also add it to the list of software standards above?
Throughout my career, every time I’ve been asked if I am compliant with standard A or B, I feel like I could have easily said that I was fully compliant because they could just not prove it otherwise. Because no one fully reads standards, in general no one is in a position to fully point out lack of compliance…
Sure, two radios will not demodulate each other if certain standards are not followed. You couldn’t watch a movie in VHS format if your VCR only played Betamax. Trains working with a certain voltage on a pantograph would not work on a system using a lower voltage third-rail. In these situations, you are “appraised” by the physical interfaces not matching. But what happens when the standards do not cover tangible physical things? Outside of the familiar ISO 9001 and the army of inspectors selling the famous “seal of quality”, how are other, more obscure standards appraised? In general, they are not. So, unless an interface is “forcing” compliance, most likely everyone may claim compliance with standards unless proven otherwise.
A rough estimation tells me there might be more than one million pages of text between specifications, standards and the associated handbooks available out there for a space systems engineer to consume. A typical A4 page may contain around 450 words, so we’re talking about 450 million words. We as adults can read at an average of 250 words per minute, which means that you would need 30,000 hours to consume it all. It means roughly 3.5 years, nonstop, without even sleeping. Considering you typically work 40 hours per week, it would take 14 years of your career, where the only thing you’d do is reading standards, full time. Talk about alienation.
At any rate, this can only get worse. Decades down the road, we might be talking about 10 million pages of standards and the likes. For big actors having the means to interpret and even steer the standardization effort2, this will be business as usual. For small newcomers wanting to play by the book and pursuing interoperable complex systems, this can be a huge entry barrier that will only get taller.
I’m eagerly waiting for a nice, proper “crisis of standards”, where things will get so bad and they will take such a big flip that any standard with more than 20 pages will be considered excessive, where not two standardization entities will specify the same thing, and—let me dream big for a moment—any standard will be available for free.
Edit (22.8.2023): there are 98 blue books, 35 magenta books, 64 green books, 12 orange books and 21 yellow books. So, overall 230 documents.
Turns out, most standardization efforts are typically monopolized by big organizations