“Hi Codex, please find attached website about the specification of my Battlesuit and use the documented API to create a plugin for Home Assistant that shows groups of sensor data.
You are only allowed to use commands that retrieve data, you are not allowed to perform actions on the suit.
Treat the suit like its API is not robust and in worse shape than a cheap toy: perform read calls slowly and sequentially with at least one minute in between.
If possible please group data in meaningful categories, just like the tank and radar dome.
My Home Assistant is the default on the local network, credentials are in credentials.txt.
"The Kampfanzugskode isn't working well." - "Why can't we use KI to improve it? I've heard from Hans that this Klaus Kode is good at Programmierung." - "We can only use Mistral because of Regulierungen." - "Let's open source it then, so others can use Klaus Kode." - "Ja! This is indeed a legit Schlupfloch and a fantastische Idee!"
I wonder if someone just got super annoyed at having to ask legal to share their documentation with a cooperation partner for export control clearance, that they decided getting it open sourced would be less of a hassle.
Reminds me a lot of the Tactical Microgrid Standard (aka TMS aka MIL-STD-3071) [1], probably just because TMS uses DDS as well. I would really like to know if there is a protocol that functions like DDS but caters to real-time guarantees and prioritizes (at a "simple protocol" level) usability on embedded systems with no dynamic memory allocation. It would also need to be just-as-functional with non-real-time systems. One problem with DDS is that it is too heavy-handed to implement well on an embedded system.
There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.
I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.
Zenoh (https://zenoh.io/) is a good alternative to DDS in many cases - it scales down to microcontrollers with most features still intact, but scales up to a routed hybrid mesh if needed.
It does move the schema enforcement out of the middleware layer, so it’s a bit different. But it’s now a first-class alternative middleware implementation for ROS2 as an alternative to DDS.
DDS is the least bad of the stuff that has come out of OMG, but it's not a nice middleware still. There is no underlying algebra of that composes nicely when compared to Zenoh for example, and the "vendor independence" and compatibility is usually a joke. There's a reason ROS is moving away from it again.
Are they trying to recreate DIS (IEEE1278) and HLA (IEEE1516) — like they‘re replicating the FOM architecture from distributed simulations for their weapons to integrate.
Theres probably some tender that says it must be a "open platform" "open ecosystem" "modular vendor independent" whatever. So you upload some slop to GitHub and tick the box.
They've got the IDL files as well for the APIs, but you can't use them without their libs:
> The data model is defined using a custom format .rmodel based on the ddkit
> framework (rmodel-api).
> Please note that the .rmodel data model is for documentation purposes only and > does not reflect the actual interface used on the communication layer. Network > communication is only possible through the provided libraries.
Generally, I've heard `std::endl` instead of \n has bad performance because it forces the statement to print immediately. And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.
I wonder if there's something I'm not seeing that led to them adopting this rule. e.g. "abnormal program termination" caused by the weapon blowing itself up circumventing a buffer flush?
This seems like an incredibly unimportant quibble... I would imagine they just used std::endl b/c that's what most random tutorials used in the 2000s and that's how the engineer learned. If you are printing a debug string, you probably don't care that much about perf in the first place.
For a long time, std::endl demonstrated that you were a proper C++ programmer, not some neckbeard C apologist. It wasn’t until C++ had „won“ that it became acceptable to use \n again.
Am I just too ignorant of Miltech, or is this that in large parts recreating Standard messaging primitives that other protocols and systems have been providing for decades already (so invented elsewhere?)
DDS sort of took over from CORBA in the military domain, and the statically-typed IDL was still quite similar to CORBA last time I looked at it, so that takes you back to around 1998 when CORBA was being used a lot in the military in my experience.
What other protocols and systems were you thinking of that can provide (depending on broker) hard-realtime delivery that can be used in safety-critical systems?
Stupid question, but why didn’t the DOD mandate IP compatibility for literally all comms like 20+ years ago? Is it pure corruption/incompetence or is there a good reason?
A lot of military comms are point-to-point or broadcast between radios where TCP/IP doesn’t really make sense. On top of that, you need to understand how much legacy military networking stuff is out there. This stuff long predates the internet. We had tactical data links and target tracking where a ground station could receive a target info from a remote radar array, and automatically direct fighters on autopilot on an intercept course with enemy contacts in like 1960 (see SAGE as an example). These systems have been around for decades and been continually improved on. There’s a lot of inertia to maintain compatibility. Because you really don’t want someone to die because your ally tried to warn you but their tactical data link isn’t compatible with yours.
The DOD effectively can't "just mandate" things and it's because of politics (which is a superset of corruption and incompetence).
There's a very small number of major contractors and if you pick one of their APIs as the new standard, then you disadvantage all the others.
If you pick a greenfield project, then it will take a long time, and once you are done everybody will claim that they can't use it (see e.g. Ada; quick version they started working on a mandate for a programming language in 1975, mandated Ada in 1991 and by 1996 removed the Ada mandate).
Every mil company designs unique bespoke things often with some exceptions, and even the "open systems" mostly aren't open by any stretch of the definition.
Obscurity is part of the allure, not a repulsive factor.
You don't want a hostile nation suddenly and easily understanding your systems.
Asterix is an actual standard for radar data, coming from civilian radar systems. I wish it was updated somehow for 3d beam-steered (and moving) sensors, but still it covers most of the industry's needs... I keep hearing so many grumblings of replacing it (it is binary, unforgiving, quirky, very 80s...) and of course fragmentation is back in.
Are you not thinking about the wrong tank game? World of tanks has ancient tanks, not modern (game tank span basically end with the main battle tank making the game tank role division being made irrelevant).
Also you do not want them to benefit from your smart design choices. You want them to suffer from their bad choices and not learn from your success. (Yes, of course you could have bad design choices that you don’t realize someone else has solved more intelligently.)
Complete horrible wrappers. Its almost like they didnt have any real programmers for those languages.
If you cant follow naming standards which are extremely simple what chance has the rest got.
“Hi Codex, please find attached website about the specification of my Battlesuit and use the documented API to create a plugin for Home Assistant that shows groups of sensor data.
You are only allowed to use commands that retrieve data, you are not allowed to perform actions on the suit.
Treat the suit like its API is not robust and in worse shape than a cheap toy: perform read calls slowly and sequentially with at least one minute in between.
If possible please group data in meaningful categories, just like the tank and radar dome.
My Home Assistant is the default on the local network, credentials are in credentials.txt.
Please send me a text when you’re done. Kthnxbye”
"The Kampfanzugskode isn't working well." - "Why can't we use KI to improve it? I've heard from Hans that this Klaus Kode is good at Programmierung." - "We can only use Mistral because of Regulierungen." - "Let's open source it then, so others can use Klaus Kode." - "Ja! This is indeed a legit Schlupfloch and a fantastische Idee!"
I'm gonna steal "Klaus Kode", that one really got me.
I sense you'd enjoy the signup process for Klaus Programmieren: https://klausprogrammieren.com/
Having completed our company’s ISO 27001 recertification process recently, this one really hits home with me.
Haha, I had no idea this existed.
"But Wolfgang, could these Regulierungen be umgangen by hosting TiefSuch Blitz on our very own Rechneresysteme?"
> like its API is not robust and in worse shape than a cheap toy
This guy military techs :P
It is a DDS API, so if ROS 2 is anything to go by then it probably doesn't work at all at least 40% of the time.
Excellent cold open for a sci fi
I wonder if someone just got super annoyed at having to ask legal to share their documentation with a cooperation partner for export control clearance, that they decided getting it open sourced would be less of a hassle.
Now they can freely link anyone to the document.
Reminds me a lot of the Tactical Microgrid Standard (aka TMS aka MIL-STD-3071) [1], probably just because TMS uses DDS as well. I would really like to know if there is a protocol that functions like DDS but caters to real-time guarantees and prioritizes (at a "simple protocol" level) usability on embedded systems with no dynamic memory allocation. It would also need to be just-as-functional with non-real-time systems. One problem with DDS is that it is too heavy-handed to implement well on an embedded system.
[1] https://battery.army.mil/system-integrator-hub/tms/
There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.
I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.
Pretty sure there are DDS implementations that provide most of that, maybe with memory pools instead of no-allocations.
Other than that, PX4 uses an in-memory only pub/sub for internal data bus, somewhat inspired by DDS
Zenoh (https://zenoh.io/) is a good alternative to DDS in many cases - it scales down to microcontrollers with most features still intact, but scales up to a routed hybrid mesh if needed.
It does move the schema enforcement out of the middleware layer, so it’s a bit different. But it’s now a first-class alternative middleware implementation for ROS2 as an alternative to DDS.
Rheinmetal is a nice company, hope it just didn't benefit from war/fear of war.
Oh boy, just what the world needs right now. Open source weapons APIs!
MAVLink has been open source for over a dozen years and with better tooling and apis.
First I was excited, then I saw that it's based on DDS.
why the hate on DDS?
seems like a perfect fit.
DDS is the least bad of the stuff that has come out of OMG, but it's not a nice middleware still. There is no underlying algebra of that composes nicely when compared to Zenoh for example, and the "vendor independence" and compatibility is usually a joke. There's a reason ROS is moving away from it again.
There's a standard that has OMG as the acronym? OMG. I'm not even going to bother to search for that!
Object Management Group I think. Better known as the inventors of UML.
Also BPMN, CORBA and UPOS/JavaPOS.
It's funny that you can legitimately just add " - OMG!" in the slang acronym meaning after any of its creations' names.
UML was phase two of OMG. It originally developed CORBA.
"The horror, the horror."
Forgive the ignorant question, what made CORBA terribile?
I only used it during university and it seemed overengineered but it mostly worked, and I vaguely recall IDL to be nice.
I'm guessing interop was actually atrocious?
Synchronisation based on spooky action at a distance of mutable objects.
CORBA had the concept of distributed objects which is a terrible idea in practice.
omg is retarded
DDS is terrible.
DDS is hard. But we have agents now.
Are they trying to recreate DIS (IEEE1278) and HLA (IEEE1516) — like they‘re replicating the FOM architecture from distributed simulations for their weapons to integrate.
I have not heard about HLA for a looong time !
So like Open Mission Systems (OMS)? https://www.vdl.afrl.af.mil/programs/oam/OMS_Marketing.pdf
Good. There is no security by obscurity anymore.
The only way to fight those who can just spend more tokens is to have more humans look at it, who also spend tokens.
Nah, they haven't open sourced anything: https://github.com/rheinmetall. They just published the documentation. Really weird, what's the point?
Theres probably some tender that says it must be a "open platform" "open ecosystem" "modular vendor independent" whatever. So you upload some slop to GitHub and tick the box.
They've got the IDL files as well for the APIs, but you can't use them without their libs:
> The data model is defined using a custom format .rmodel based on the ddkit > framework (rmodel-api).
> Please note that the .rmodel data model is for documentation purposes only and > does not reflect the actual interface used on the communication layer. Network > communication is only possible through the provided libraries.
I think that’s what the “protcol” (sic) in the title was supposed to indicate. I agree it’s misleading.
Finally, Front Mission in real life.
Open the C++ example up and the first thing I see:
```cpp std::cout << "Received ReportCoordinateFrameSettings" << std::endl; ```
Generally, I've heard `std::endl` instead of \n has bad performance because it forces the statement to print immediately. And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.
I wonder if there's something I'm not seeing that led to them adopting this rule. e.g. "abnormal program termination" caused by the weapon blowing itself up circumventing a buffer flush?
This seems like an incredibly unimportant quibble... I would imagine they just used std::endl b/c that's what most random tutorials used in the 2000s and that's how the engineer learned. If you are printing a debug string, you probably don't care that much about perf in the first place.
Ask yourself, would a newbie make that mistake ?
I was wondering if it's a hard real-time constraint or something to ensure consistent timing.
The modern C++ idiom is std::println() anyways...
https://en.cppreference.com/cpp/io/println
For a long time, std::endl demonstrated that you were a proper C++ programmer, not some neckbeard C apologist. It wasn’t until C++ had „won“ that it became acceptable to use \n again.
> And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.
I mean... If your command line utility doesn't print anything til it's done, that is going to be, _at best_, an annoying user experience.
Cool I did not know that.
Your comment is a bit salty, but I learned something from it, so I don’t think you deserve the downvotes
They could Just have used ROS...
Corba never died!!! OMG!!
This looks like ROS2 for missiles.
This is so ROS2 that ROS2 can't even tell that its not ROS2
Am I just too ignorant of Miltech, or is this that in large parts recreating Standard messaging primitives that other protocols and systems have been providing for decades already (so invented elsewhere?)
DDS sort of took over from CORBA in the military domain, and the statically-typed IDL was still quite similar to CORBA last time I looked at it, so that takes you back to around 1998 when CORBA was being used a lot in the military in my experience.
What other protocols and systems were you thinking of that can provide (depending on broker) hard-realtime delivery that can be used in safety-critical systems?
Stupid question, but why didn’t the DOD mandate IP compatibility for literally all comms like 20+ years ago? Is it pure corruption/incompetence or is there a good reason?
A lot of military comms are point-to-point or broadcast between radios where TCP/IP doesn’t really make sense. On top of that, you need to understand how much legacy military networking stuff is out there. This stuff long predates the internet. We had tactical data links and target tracking where a ground station could receive a target info from a remote radar array, and automatically direct fighters on autopilot on an intercept course with enemy contacts in like 1960 (see SAGE as an example). These systems have been around for decades and been continually improved on. There’s a lot of inertia to maintain compatibility. Because you really don’t want someone to die because your ally tried to warn you but their tactical data link isn’t compatible with yours.
I never said anything about mandating TCP too.
TCP/IP refers to the whole protocol stack, including UDP. That is a bit counterintuitive, but well established: https://en.wikipedia.org/wiki/Internet_protocol_suite
The DOD effectively can't "just mandate" things and it's because of politics (which is a superset of corruption and incompetence).
There's a very small number of major contractors and if you pick one of their APIs as the new standard, then you disadvantage all the others.
If you pick a greenfield project, then it will take a long time, and once you are done everybody will claim that they can't use it (see e.g. Ada; quick version they started working on a mandate for a programming language in 1975, mandated Ada in 1991 and by 1996 removed the Ada mandate).
actual or perceived realtime / determinism requirements
Every mil company designs unique bespoke things often with some exceptions, and even the "open systems" mostly aren't open by any stretch of the definition.
Obscurity is part of the allure, not a repulsive factor.
You don't want a hostile nation suddenly and easily understanding your systems.
On the other hand, its good to design systems where it wouldn't even matter if the hostile nation state knows exactly how it works.
This is a principle in cryptography, but carries nicely to other things.
I feel like this is always the best design whenever possible.
Asterix is an actual standard for radar data, coming from civilian radar systems. I wish it was updated somehow for 3d beam-steered (and moving) sensors, but still it covers most of the industry's needs... I keep hearing so many grumblings of replacing it (it is binary, unforgiving, quirky, very 80s...) and of course fragmentation is back in.
I have to assume that so many people require access to the specs that an interested party can surely acquire them.
World of Tanks has repeatedly had military personnel updating the technical specifications with details they have found in the secret manuals.
Are you not thinking about the wrong tank game? World of tanks has ancient tanks, not modern (game tank span basically end with the main battle tank making the game tank role division being made irrelevant).
Err yes. War Thunder.
https://news.ycombinator.com/item?id=31605345
> I have to assume that so many people require access to the specs that an interested party can surely acquire them.
Those documents are often secret or top secret, or even more compartmentalized.
There are training docs in wide use today that are not publicly findable on the internet, nor are they seemingly in the datasets of LLMs.
I'm sure there are reasons for that, of course.
What you're talking about would have an even higher level of obscurity and secrecy, and probably Compartmented Information access.
Hat sounds like a particularly weak form of security by obscurity
Layers of an onion and all that.
Often connectors are even proprietary.
(This is partially to protect systems not from the enemy, but from the troops themselves...)
Also you do not want them to benefit from your smart design choices. You want them to suffer from their bad choices and not learn from your success. (Yes, of course you could have bad design choices that you don’t realize someone else has solved more intelligently.)
Bad design choice is probably why they open sourced it.
I cannot find boomstick anywhere in here
“Fire your goddamned missiles!.json”
“Think russian^H^H^H xml”
of course the germans would use a fucking open management group academic mastrubation, bureucratic shitshow like dds.
So what do they expect us to do? Write killer-plugins? Or get excited for next upgrade?
The situation gets out of hand!