This month topic in #spacedonewrong is fear. Once again the European Space Agency has chosen a canonical platform which is unfortunately unsuited to meet the programmatic requirements. For me his looks like another case of “lets stick with what we know”.
Its Groundhog day: EC/ESA IOD Element 2 has again ended up with a platform that is unsuited for the top level requirements
This second IOD contract has been handed out to OHB Sweden. Like “Element 1” ESA has chosen a platform which (once finished) will undoubtedly be formidable. Whether it is a good choice on a programmatic level is again highly questionable. Lets have a look!
Introduction
In Orbit Demonstration (IOD) is an important category of space missions. It is intended to overcome the problem of “has not flown – will not fly”. Element 2 is the second IOD mission that has been funded by the European Commission (EC). EC gave the task to implement this mission to the European Space Agency (ESA). ESA has contracted OHB Sweden to build the IOD carrier satellite.
IOD are important for the European Space Industry. Considering the questionable choices by ESA and actual IOD availability in the industry future IOD programs should be directly handled by industry with no space agency overheads!
A more detailed introduction on IOD missions and how the European Commission and the European Space Agency are involved can be found in the previous article on this topic: It is part of the #spacedonewrong series and called: “lets stick with what we know”.
About Element 2
The payload of EC/ESA IOD Element 2 is the ELOIS [1]. ELOIS is a hyperspectral payload being developed by a European consortium around the Belgium company Amos. ELOIS packs quite the punch [2],[3]: it matches the performance of much larger platforms like the Italian Prisma [4] or the German Enmap [5] (still under development).
Note: since the payload was mentioned publicly by name I was able to include a more detailed technical analysis based on publicly available data. The sources [xx] used for this can be found at the end of this article.
This payload with had #1 in the EC/ESA IOD list has be separated from the rest of the payloads as it became apparent that the payload itself would likely not meet the 2 year development schedule (details can be found in the previous article). On the plus side that means that the IOD mission with be simple from an organisational perspective, it is however also true that the payload is by far the most demanding of all EC/ESA IOD payloads.
This outstanding requirements cover all elements: size, mass, ADCS & data chain.
About InnoSat SML
The InnoSat platform is the flagship micro satellite product of OHB Sweden. It comes in three distinct sizes: Small, Medium, Large (SML).
Due to the size of the ELOIS platform the Large Version from InnoSat is required. The small InnoSat has flown in the GMS-T mission (early 2021) and the medium version will fly later 2021. The 1st version of Large InnoSat has been contracted in March 2021 and will fly in Q1 2024 [14]. That means while S is flown & M is qualified, L still needs much development!
GMS-T is an IOD mission that has been implemented by OHB Sweden outside an agency context in a lightning fast speed of 6 month. This shows what the European space industry is able to deliver – on their own – based on existing/heritage platforms.
Sadly, IOD Element 2 is not representative for one (industry only) or the other (heritage).
Interestingly the InnoSat Webpage of OHB Sweden seems to have a bit of confusion regarding the capabilities of the platform. Below the data from the website [10].
The new datasheet is from March 2021, it was published alongside with winning the ESA AWS tender. From the differences between the information set and the timeline it seems rather likely that the new flyer is a biproduct of either the AWS tender or the preparation of the ESA IOD bid and does not represent the heritage capabilities of the platform.
In March 2021 InnoSat Large increased capabilities. These are not heritage, they are being developed for AWS & ESA IOD.
I think it is safe to assume that all increases in capabilities that are shown in the tender are actually not yet existent (under development, very likely as part of AWS and to a greater extend ESA IOD). Interestingly the ADCS performance that is given in the old document is pointing towards larger platform (higher accuracy, lower slew rate due to higher moment of inertia). Since these values (APE & AKE) are lower in the new flyer this likely indicates the current status of the design. Another observation that can be made is that the ADCS system claims very accuracy. This is likely as heritage from the Prisma formation flying mission [16] – note not to be confused with the Italian hyperspectral mission of the same name. The slewing capacity of the satellite which is given in deg/min (not deg/sec!) indicated that the system was designed for a much smaller satellite and likely in addition for nadir operation only. This is in line with all heritage missions of OHB SE (and prior SSC) which did not require such manoeuvres. It should be observed however that a 3°/min slew rate for the InnoSat L means that the satellite in its largest configuration can not even be operated in Nadir mode. The reason is that in a 100min LEO orbit the satellite – at maximum wheel speed – could rotate only 300° instead of the necessary 360°. With the wheels of the base configuration the InnoSat L (at max payload size of 50-80kg) is therefore likely only useful for inertial pointing missions.
Here is what I find strange
Fact: ESA contracted OHB Sweden 32.5 MEUR to build the prototype of the Artic Weather Satellite (AWS) [6]. This mission includes the bus, the payload, ground segment and mission operation.
Question: If ESA AWS was contracted for 32.5 MEUR, how is it possible that IOD Element 2 for ELOIS can run on a mission budget of just 8 MEUR?
It should be considered that while the two payloads (AWS Radiometer & ELOIS) have roughly the same size and power requirements, ELOIS is by far the more demanding payload due to its internal data rate (500x) and ADCS (Agile vs. nadir only) – ELOIS will thus require significant more planning, development, implementation as well as operation effort as AWS. Main redeeming factor for AWS is that Element 2 does not include the payload. However, only if we assume that the AWS payload makes >3/4 of the mission cost then we can assume that the InnoSat Large bus is at a price range where it would fit the mission budget.
Fact: There is an option to build 16 serial satellites of AWS but this is to be decided after the launch of the first prototype (after Q1 2024)
Question: Was the assumption that the price for the IOD mission (Element 2) can be reached once the serial production of AWS satellites is running?
If so, isn’t this violating tender rules that the IOD mission should not assume the winning of an independent mission? The rule were towards Element 1 but should hold also for other missions.
Tender violation aside, if the plan is to use a serial produced AWS bus (for cost reduction), then at the very least this would mean a completion 12 month after AWS (recurrent satellites at 12 month) and therefore sometime in 2025? How would that be compatible with the mission requirement of having a launch T0+24 month?
AWS and ESA IOD Element 2 use the same platform. The latter having significantly increased performance (additional NRE). Yet AWS has a sticker price of 32MEUR and IOD 8 MEUR.
Fact: OHB SE claims that delivery time for the InnoSat platform is 18-24 month including system AIT [10], yet the delivery of the Artic Weather Satellite (InnoSat Large) will only fly in 2024. Given that the contract has been signed in March 2021 this indicates a development time of 36 month.
Question: If InnoSat Large (as shown in AWS) has in fact a 36 month delivery time, how does that fit to the requirement of a fast mission for IOD?
Fact: OHB Sweden claims that InnoSat is built using “a newspace approach” with “no delta development” and claims that the development time is 18-24 month, yet the first mission (AWS) is 36+ month.
Questions: Does that mean that the A) the platform is ready but implementing it inside ESA adds 50-100% implementation time or B) the platform is not ready yet and thus unsuited for the scope of the ESA IOD mission. Your guess is as good as mine.
Fact: ESA AWS was signed in Q1 2021 and is slated to be finished in Q1 2024. EC/ESA Element 2 was signed in Q3 2021 and is slated to finish Q1 2024, too.
Questions: How is it realistic to start a mission 6 month later using the same platform and process then add significant NRE on top yet hope to finish at the same time?
In the EO missions that I experienced no bus subsystem required more development time as the high speed data handling.
To add that to an AWS bus (which has none) will result in significant NRE.
Fact: All the flown (and qualified) reference missions of InnoSat have very low payload data rates. Internal data storage is small (56 GB) and standard communication offers only TM/TC [10] but no high speed data. ELOIS on the other hand has a payload data rate of >500Mbit/s [12]. Therefore, a complete high speed data processing, storage, compression and transmission system will have to be added to the mission which is not yet part of the platform. Since AWS likely has a payload data rate of <1 Mbit/s [15] and thus no high speed data transmitter this system will be a new development for Element 2 which will add significant mission complexity.
Question: If the data processing and high speed transmission system still has to be developed/implemented for ELOIS, how is this compatible with the top level requirement that the ESA IOD carrier should limit the development as much as possible?
Element 2 has a significantly more complex ADCS and data processing and data transmission chain than AWS. All of which will be new developments. This makes this timeline even more unrealistic.
Fact: All reference missions of InnoSat (SML) are 100% Nadir oriented. This is a much simpler operation scenario than required for ELOIS. The data sheet seem to indicate an heritage only for very slow slew rates.
InnoSat Large offers >3°/minute in the base configuration. At largest capacity this is not even sufficient for a Nadir only operation.
In addition the reaction wheels of InnoSat are way too small! For InnoSat Large (AWS and Element 2) the achievable rate is a few degree per minute. Who ever designed their ADCS probably only had Nadir pointing missions in mind (hint hint).
According to the InnoSat Datasheet there is a “high performance” ADCS option.
With up to 25°/minute (0.42°/s) this is still too low for demanding missions like ELOIS.
ELOIS does requires precise and highly agile platform. These are capabilities that InnoSat has not yet shown. As a result ADCS will likely need a be implemented as a first for the ELOIS mission. Since to my understanding the AWS is a 100% nadir mission, too it is likely that this is actually a completely new development which will add significant complexity.
Question: If the ADCS (one of the most complex bus subsystems of any EO mission) needs to be improved drastically and consequently significant R&D is required, how is this compatible with the top level requirement that the ESA IOD carrier should limit the development as much as possible?
Fun Fact: Industry is fully capable of running commercial IOD programs. GMS-T built by OHB Sweden was implemented in record speed, fully commercial and without the need of a space agency umbrella.
Fact: OHB Sweden has build the GMS-T satellite (based on InnoSat Small) in <6 month. This was in a commercially funded IOD mission outside the usual ESA environment. The mission was Bring Into Use (BIU), which is essentially a category of IOD. This was possible because OHB SE was not held back by agency overheads and could use a platform on which (unlike InnoSat L) they had heritage.
Question: Could this be yet another indicator that simple missions (like IOD) are better done A) outside the ESA framework and B) with an actually flight proven platform?
What would I have done different
To get that out of the way: I have no doubt that OHB-SE, the chosen supplier will deliver to the required technical specification. However, the programmatic top level requirements asked for a fast mission implementation based on a qualified platform. On this ESA failed to deliver.
In Element 2 ESA failed again to select a platform that fits the top level requirements.
It is very visible that the InnoSat SML platform does not have the required performance for the ELOIS IOD mission yet. To implement it will very likely cost more money and time as was budgeted in Element 2. Time will tell whether we will once again see excessive use CCN’s like in so many ESA run missions before.
Looking at the quoted cost figure and the required NRE I expect that ELOIS will see many CCN’s, cost overruns and delays.
Since affordability and speed by using a qualified platform were the core requirements it is visible that the selected carrier is incompatible with key mission requirements. Instead of being selected it should have been rejected from the tender.
I personally would have loved to see ESA pick a flight proven platform with significantly less NRE and a better chance to keep budget and schedule.
Recommendations
Since ESA made similar choices as with Element 1, thus selected a canon supplier even if the solution does not fit the programmatic requirements, my recommendation therefore stays the same, too: have more confidence in the European space industry!
European Commission
Dear European Commission please give future IOD contracts directly to Industry without the ESA detour. You will be able to implement more of your goals, in less time and for less expenditure. Or are you not interested in Getting more for bang your buck?
Trust the European space industry more. Less overheads, less paper , more results.
If you don’t want to take this recommendation from me, just look what OHB-SE was able to achieve with GMS-T
European Space Agency
Dear European Space Agency, if a 8 MEUR mission is still too big for you to consider to give it to someone outside your usual circles, then maybe reduce the overheads and enjoy the availability of flight proven European satellite carriers that take a fraction of the cost and time. The opportunity may be a lost for Element 2 but like Phil Connors, your groundhog day will continue until you finally find a way out. Once you do #newspace is there for you!
How can you help:
This text is part of a series of articles in which the author sets the framework to start a discussion about the wrongs of the space industry. If you have experienced similar things, leave a comment. Other views and opinions are very welcome, too, as they may present a way forward. Please be kind to each other.
Disclaimer
The author’s views are his own do not represent the views of his company Berlin Space Technologies.
Sources:
[1] General information on ELOIS – Amos Website 12.09.2021
[2] “Freeform grating-based hyperspectral instruments: when SmallSat solutions benefit to big missions” Vincent Moreau et. all, Utah Smallsat 2019
[3] ELOIS Datasheet – Amos Website 12.09.2021
[4] Prisma Hyperspectral Satellite – EO Portal 12.09.2021
[5] Enmap Hyperspectral Satellite – EO Portal 12.09.2021
[6] Artic Weather satellite cost – OHB Webpage 12.09.2021
[7] Artic Weather Satellite mission – ESA Webpage 12.09.2021
[8] MATS Mission – EO Portal 12.09.2021
[9] GMS-T – OHB Sweden Website 12.09.2021
[10] Innosat platform capabilities – OHB Sweden Website 12.09.2021
[11] ELOIS Detector – Caeleste Webpage 12.09.2021
[12] ELOIS Data Rate = 500Mbit/s [2], potentially higher (see below)
- Input Data: 200 channels, 70km swath, VNIR GSD = 35m, SWIR GSD 35/70m GSD.
- 7000m/s ground speed & 35m GSD = 200lines/s per channel
- 7000m/s ground speed & 70m GSD = 100lines/s per channel
- SNR of 400 requires 16bit
- VNIR data = 2000px * 200lines/s per channel * 100 channels * 16 bit/pixel = 640Mbit/s
- SWIR data = 1000px * 100lines/s per channel * 100 channels * 16 bit/pixel = 160Mbit/s
- Data per pass (10min) = 500Mbit * 600s = 300 Gbit (raw data)
- Conclusion: ELOIS has >1000x the internal data rate of AWS and >100x the total data rate assuming 1 pass per day. Therefore ELOIS needs a high speed data chain and transmitter (>100Mbit/s).
[13] InnoSat ADCS performance
- All reference missions are nadir pointing only (no high agility)
- APE – Absolute Pointing Error, 40mdeg 2sigma
- AKE – Absolute Knowledge Error, 15mdeg 2 sigma
[14] Innosat Datasheet – OHB Sweden Webpage 12.09.2021
[15] AWS data rate
- Input Data [7]: 0.75 lines / s (45rpm), ~1° iFOV (>10km GSD), 19 channels
- Data Max = 360° / 1°/px * 0.75 lines/s per channel * 19 channels * 16bit/pixel < 0.1 Mbit/s
- Data Volume (360°) = 86,400s * 0.1Mbit/s = 8.4 Gbit / day
- Data Volume (Earth ~ 120°) = 2.9 Gbit / day (uncompressed)
- Transmit Time = 2.9 Gbit / day / 4 Mbit (S-Band) = 720s (12min)
- 2-3 passes per day at 5-7 min per ground station -> AWS has no high speed data transmitter!
[16] Prisma formation flying mission – EOportal website 16.09.2021
Leave a Reply