In times when entitled lunatics wielding chainsaws are coming to gift us “efficiency” and save us from overhead and bureaucracy, I want to hop on that wagon for a brief second and join the lunacy in a very selective manner: review the ECSS system and see what purpose it serves in the quest of creating space systems in Europe, and propose what could change to adapt it to the current times.
Sure, as a non-European living in Europe and writing a critique of a European thing, you could ask me to just go back to my country and criticize things there, and you would be in your right to do so. But hey, as the Mars-dreaming, attention-seeking lunatic teaches us on his social media platform, free speech is a thing after all, and this is a place where I say what I want. Opinions are mine, and reading these lines is always an act of free will. You are free to leave now if you want!
What is this ECSS thing after all, what does it represent, and why am I about to rant about it? The European Cooperation for Space Standardization (ECSS) is a collaboration between the European Space Agency (ESA), the European space industry (represented by certain selected, privileged entities), and some space agencies, to “develop and maintain a single set of user-friendly1 requirements for use in all European space activities”.
First problem. They use the word “standardisation”, in their name. In reality, ECSS is a big, BIG, humongous collection of requirements. Mandates. Statements that order you to do X or Y if you plan to do space the European way. Is that real standardization? I beg to differ. To me, a standard is a set of specifications mostly to ensure interoperability. Standards are supposed to be specific, technically sound, and focused. Bluetooth is a standard, in a way your phone can work with your earphones so you can listen to Taylor Swift while you’re at the gym. 3GPP produces heavy, complex standards for 4G/LTE and 5G so you can watch TikTok from your Finnish-subscription phone while you’re in Shanghai for business. Ethernet is a fat family of standards so data can flow seamlessly across dissimilar networks. Those are real standards in my dictionary2. Is ECSS a standard in that regard? Well, you could have two space missions being completely ECSS-compliant and still be, painfully, abysmally un-interoperable—if that’s even a real word.
Ok but what does the ECSS organization do? It maintains what is called the “ECSS System”: a somewhat messy, inflated, convoluted, and conservative ball of requirements. In fact, at the time of writing, it is made of almost 30,000 requirements.
Yes. Thirty-thousand.
The ECSS System in numbers below:
All packed in 136 active documents plethoric with requirements. You can smell the taxpayer’s euros burning while skimming through this slide, can’t you? And yes, you must be thinking, wait, why are the Europeans imposing requirements on space missions, including commercial missions? Doesn’t basically every space mission have its own set of specific requirements and technical performance measures, like mass, power, pointing, software, etc? Yes, of course. But the European way is to add on top of all the mission-specific requirements your mission must comply with, 30,000 requirements more that kinda come to prescribe your design and development process as well. This is a key factor here: You thought you could design your space system according to your experience, education, and lessons learned? Think again: the ECSS targets the design subject (the space thingy that flies) but also the design process itself, blurring the line between the two and issuing documents without clearly stating if targeting the system under design or the design. This is almost primary-school Systems Engineering—knowing your subject and drawing the line between the process and the thing that the process transforms.
It’s worth mentioning that there is no certification process whatsoever to define if something is officially ECSS-compliant or not. This is an extract from their policy document:
So, unlike when you try to certify ISO-9001 or be Bluetooth compatible, you can’t get an ECSS logo sticker on your website or your satellite. Therefore, claiming ECSS compliance is mostly an act of faith: no one will really check if you are compliant at the requirement level. But this doesn’t mean they won’t make you suffer in the process and try to make you compliant at the DRD level. We will see what DRDs are soon.
In terms of the organization, ECSS requirements are distributed in a “tree” that contains several specialized branches. See the image below.
The branches are: Management (M-branch), product assurance (Q-branch), engineering (E-branch), sustainability (U-branch), and Industrialization (I-branch). By far the Q and E branches are the main ones and contain most of the requirements (if we go back to the “ECSS in numbers” slide from above, you’ll see that Q+E contains roughly 27,000 requirements. Please don’t be fooled by the simplicity of the tree diagram above. Each box of that diagram contains many, MANY more documents. See for instance just the blue branch (Q-branch) expanded:
Looking at all these document trees, you can almost perceive how things seem to get more useful, at least by title, the lower you go in the branches. This should be no surprise: documents get more technical as you go down the branches, as opposed to the abstract/managerial documents at the top.
Here’s the beauty of it. Whether you are designing a mission carrying a group of Boy Scouts to terraform Venus or a tiny Cubesat for a University, those 30,000 requirements will cast a dark shadow on your project, making everyone’s life rather hard in the process. Sure, you only need to comply with ALL 30,000 if your lucky stars really hate you. For instance, by having a space agency involved in your mission, either directly or indirectly. With an agency as a customer, this is the most extreme shitshow scenario, where an army of entitled bureaucrats will lecture you on how to do things when probably you have ten times more practical experience launching things into space than them. In some cases, they will be really young bureaucrats who have literally zero industry traction but will still pull rank with their institutional email handles, lecturing you—in the most boring tone ever—about the benefits of embracing The Standards and adopting the best quality methods (EDIT: I know I’ve hit a nerve when, after sharing this post in LinkedIn, the bureaucrats are crawling into my DMs trying to lecture me about ECSS. We love you, never change).
If an agency is not your direct customer, you probably still need to deal with the insufferable bureaucrats because it means you probably are in consortia—many things in the European space sector seem to work within consortia3—with probably one of the big guns in the European space scene. You know who I’m talking about, no need to name them. The Big Guns are always very active in siphoning money from governments and European institutions by forming these strange little cliques with random small companies they actively enslave and force to comply with the reigning red tape.
The complete, unhandled shitshow unleashes if you’re in a mission classified as “highly critical” by the ECSS system. That is somewhat loosely called “class I” and it’s the highest mission class and somehow makes ALL damn ECSS requirements applicable.
Missions with lower classification are not even close to being safe from harm, because lower classification opens the door to another unhandled, unbounded clusterfuck which is the tailoring process, that is, deciding which of the 30,000 requirements apply to your missions vs not. Believe me, burning me with hot candle wax while hitting my toes with a rusty hammer while hanging upside down outside on a cold winter early morning is a more pleasant experience than having to tailor ECSS requirements. Mind you: the tailoring process is still being discovered as we speak; even the ECSS org doesn’t say much about it, and the few documents about the tailoring process have been marked as DRAFT for half a decade already, so there are still many questions open that no one can answer, including the bureaucrats. But hear this: a mission marked with a certain class can contain units/payloads/components with different classes. Mission class is defined at the project/mission level, but it’s possible to conceive different classes for different mission elements in the product tree. Amazing.
Besides any emotionality I might still carry with me after dealing with the ECSS System for an extended time in my mediocre career, many ECSS requirements are objectively bad and shouldn’t be there. Badly written, innocuous, obvious. Many are just unmeasurable, breaking the sacred SMART framework4 bureaucrats like so much to preach about. See this one (from ECSS-Q-ST-20C-Rev.2, Quality Assurance).
Wow. Thanks a lot. Isn’t this, like, common sense? I understand I might come across as too strict and picky, but my argument is that this is one of the main reasons why the ECSS System gets so out of control: one platitude at a time.
Besides pointless requirements like this that are mostly there only to fill space and increase page count, it’s also the semantic artifacts that are everywhere. See this lovely paradoxical one (source: ECSS-P-00C, the document that sets the ECSS policy):
Say again? Saying that the core of the system is the complete set contradicts the usual meaning of "core". The core of something is typically a central or essential part, not the whole. Is the core of the peach the peach? Can a peach be a peach without its core? What is a peach, after all? But well, I guess semantic consistency or even decent proofreading is not something the ECSS team is really fond of. Some passages are so cumbersome to follow, forcing you to open ten different documents to understand a simple concept. See this extract below from here:
Geez.
DRDs and The Urge to Justify the Unjustifiable
And now we arrive at the DRDs. Oh, the DRDs! How many hours have startup teams spent writing them? So many memories. But what are DRDs? Well, *any* requirement in ECSS may freely spawn and vomit a document. That’s a DRD. DRD stands for “Document Requirements Definition” and according to ECSS, it’s not about the “form” but only about the scope and content that is mandatory (what “form” even means here, I do not know). Exercise for the reader: find the typo in the blurb below (from here):
Now, why are DRDs so relevant? Well, of course, no one in their sane mind would go check requirement by requirement in a typical space mission, so reviewers will lazily zoom out from the 30,000 requirements shitshow and focus on the DRDs. DRDs act as a sort of “filter” from the ECSS jungle of requirements. Reviewers will then go:
— Do you have the Critical Items List (CIL)?
— Do you have the Product Assurance Plan (PAP)?
— Do you have the Declared Mechanical Parts List (DMPL)?
— Do you have the Declared Materials List (DML)?
— Do you have the Integration Plan, Verification Plan, Validation Plan, the Plan of the Plan?
And you better have them, or the wrath of bureaucracy may fall on you with full force.
Every engineering project in the world generates information as it goes through its life cycle. This information tends to be a loose collection of spreadsheets, domain-specific files (from EDA/CAD tools), testing reports, architecture diagrams, sketches, and whatnot. Sure, it tends to be a messy hairball of information, but this reflects more or less the messy nature of the design process itself. Design is about bringing order from disorder, and the informational side of design follows the same path. Now, ECSS somehow steps in again and tries to force order in the design process by requesting keeping something called a “Design Definition File” (note, “file” here does not mean a single file sitting on a hard disk but a file as in a collection of documents, see photo below).
The ECSS-E-ST-10C talks about these files, and specifies their structure in Annexes:
I mean, it kind of feels again like trying to prescribe common sense. It feels like double work having to deal with all the information that a design process generates AND having to structure it and present it the way the ECSS wants you to. If the builders can provide evidence their design is progressing accordingly, does it need to be structured in a specific way?
But that’s not the main problem with these files. The puzzling part is the “justification” part. See what the definition of the DJF says:
“The objective of the design justification file (DJF) is to present the rationale for the selection of the design solution, and to demonstrate that the design meets the baseline requirements.”
I’ve been in projects where reviewers really insisted to have the DJF and believe me, we found our way to bullshit ourselves out of the situation, but the bewilderment about this DJF stayed with me. How do you really “justify” that a design meets the baseline requirements in a document?
Isn’t that “justification” THE reason why we engineers do what we do? Isn’t that the main idea behind designing anything? Don’t we “justify” our designs by painstakingly going through the system lifecycle stages, where we incrementally verify that our decisions are more or less correct, and if they are not, we apply corrections and iterate until they are?
I will say this out loud, just for cathartic purposes: the DJF makes NO SENSE, and NO DOCUMENT or set of documents can capture the true justification of a complex design. Go to an aircraft manufacturer and ask them to “justify” why their most popular single-aisle plane looks like it does. What will they say? They will probably say: I don’t know man, there is no single justification possible, but a practically infinite sequence of iterative decisions that have been tried. Some worked, some didn’t. The ones that worked, well, they kind of justified themselves.
The Lost Forgotten Paradigm
In theory, the ECSS requirements are written following something called the “ODSI” paradigm5, which is not well documented in ECSS material. See what it means:
Somehow, the bureaucrats at some point forgot about their own paradigm and stopped letting industrial actors follow it, for example by letting them “organize the activity their own way”. On the contrary, any attempt to go against what the DRDs exactly dictate has been presented with the most stubborn reluctance. It’s about time the ECSS team overcomes the collective amnesia and remembers back the paradigm THEY came up with and either trash it for good, or (finally) honor it.
The Zero-Debris Problem
I am a strong advocate of sustainable space. In fact, I wrote an entire section about it in my book “NewSpace Systems Engineering6” (see Chapter 1, Section 1.5). Additionally, I wrote an OpEd in SpaceNews where I clearly stated that you must not launch low-quality stuff for the sake of launching and that capitalist market forces should not dictate in isolation what is worth going to space.
In Europe, ESA has laid out its zero debris policy in the form of a set of “recommendations”. In particular, the one about disposal is an itchy one and it’s creating quite some pain in the startup community. The recommendation goes like this:
“Ensuring the safe disposal of space objects is of utmost importance. ‘Self disposal’ through atmospheric reentry or reorbiting to a safe altitude should be verified in advance of a mission’s launch, with a probability of success higher than a certain minimum threshold (currently set at 90%). Critical disposal functions – such as enough fuel for manoeuvres, functioning thrusters, etc – should be continuously monitored. Missions should also include interfaces that would help the mission be more easily removed from orbit, should self-disposal fail.“We are aiming for rules that compare to every national park on Earth – what you bring in you must take with you when you leave”.
Sure, transpires as reasonable, although a tad futuristic when it talks about “interfaces that would help the mission be more easily removed from orbit”. We will ignore that for now, and focus on the rest. The problem with this recommendation is that is being enforced without observing the nuances of the missions involved. A short-lifetime IOD from a startup is being put under the “zero-debris” magnifier the same way as a mission to explore the dark depths of Uranus carried by a space agency, ignoring the fact small organizations might not have the resources to meet this requirement. This translates into a Product Assurance nightmare where, in the name of quality, small companies are forced to design things like the James Webb Space Telescope, even for small CubeSats demonstrating some technology for a short limited time.
Again, no one is against a sustainable use of space, but NewSpace is about risk-taking, and a zero-risk-taking policy will eventually break NewSpace down if it continues this way. Additionally, any zero-debris policy makes sense on a global scale. If a particular continent is super careful with space debris but another continent or country is absolutely reckless, the problem is still there, isn’t it?
If The Chainsaw Comes, Save the Handbooks
All that being said, if an occasional lunatic comes with a figurative chainsaw to put all the overhead and red tape to a well-deserved rest, let’s make sure we save the ECSS handbooks. Handbooks are fine. And, in my opinion, ECSS handbooks capture what ECSS should have always been about and should have never, ever departed from: disseminating knowledge, lessons learned, and good practices in clear language, with examples, and with good references. ECSS has some good handbooks that are non-normative (you are not forced to follow what they state). Somehow, it feels like the ECSS folks took a wrong turn at a certain point and self-propelled each other into a requirement-writing frenzy that shouldn’t have been. There are great handbooks about control design, radiation mitigation, electromagnetic compatibility, and whatnot. Of course, keep a critical eye, as there are also some handbooks you should be careful of consuming; mainly those that just flex the ECSS approach and urge you to blindly adopt it and reinvent what you studied in engineering school, I’m looking at you, software engineering handbook. Careful with that one.
Conclusion: Careful With Killing an Industry With Overcompliance
It is about time European decision-makers realize that the continent has a very high-potential, competent space startup scene going on, and act accordingly. A startup environment that knows the risks and it’s not stupid. The current approach of choking startups with dull DRDs, eternal requirements, and obscure tailoring is killing the magic and the joy, one matrix of compliance at a time. In startups, there is this sense of urgency that must be finally understood by policymakers coming from dissimilar frames of reference like space agencies.
To finalize. This is not a standards are bad manifesto. Standards are good when done right, and when applied right. In fact, the reason why I can write this article and you can read it is thanks to a myriad of standards put together by the tireless work of organizations like IETF, ISO, IEEE, and many, many others.
Here are my humble suggestions to the ECSS folks (who of course will never read this, but here I go anyway):
Cut all the platitudes, the innocuous stuff, the things that point to common sense, the filler. Bring those 30,000 requirements to a tiny fraction of that.
Let the builders decide what is critical and how to keep track of it
Let the builders justify their designs by just going through the system life cycle
Remove yourself from prescribing the design process
Focus on the handbooks, spread knowledge, spread lessons learned, and good practices
Stay free and accessible as you are :-)
The user-friendly bit kills me every time I read it.
The European Space Program is Dying, And No One Wants to Admit It
If you need a living example of the effects of design by committee, look no further: see the European space program. Cursed by its geographically and culturally distributed nature, the sector is famous for trying to do space technology by forming a cloud of zombie consortia fueled by taxpayers’ money. Someone said a long time ago: if you want something NOT to get sorted out, go form a committee. Europe is the living proof of the axiom.
https://en.wikipedia.org/wiki/SMART_criteria
Here you can find more info about ODSI (section 5.2.7): https://ecss.nl/wp-content/uploads/2023/03/ESSB-HB-S-001-Issue1(1February2018).pdf
https://link.springer.com/book/10.1007/978-3-030-66898-3