| |
| ▲ | anonymousiam a day ago | parent [-] | | This assumes that the operating system can run. If the memory corruption impacts the OS, then it may be impossible to recover. As the systems (and software) have become more complex, keeping these Mission Assurance best practices becomes more important, but the modern generation of developers sometimes loses sight of this. A good example of what I'm talking about is a program that I was peripherally involved with about 15 years ago. The lead wanted to abstract the mundane details from the users (on the ground), so they would just "register intent" with the spacecraft, and it would figure out how to do what was wanted. The lead also wanted to eliminate features such as "memory dump", which is critical to the anomaly resolution process. If I had been on that team, I would have raised hell, but I wasn't, and at the time, I needed that team lead as an ally. | | |
| ▲ | dahart 10 hours ago | parent | next [-] | | Do satellite embedded satellite systems usually have an OS these days? Is this a custom made OS, or do you have any examples of an OS that honors the no stack/heap and fixed address requirements you mentioned? What does the OS do? I don’t know about aerospace specifically, but plenty of embedded microcontroller systems don’t have an OS, and I would assume that having an OS is a massive risk against any mission assurance goals, no? | | |
| ▲ | anonymousiam 7 hours ago | parent [-] | | It's a mixed bag. Some programs use Green Hills Integrity, some use Wind River VxWorks, some roll their own. I've done all of the above. The main purpose of the OS is to centralize, schedule, and manage the resources needed for the mission. It's usually pretty lightweight. Different philosophies are used on different missions. The OS risks can be mitigated. Usually there's a backup "golden copy" OS that can boot if needed. There's also "Safe Mode", which prioritizes communications with the ground, so anomalies can be worked. |
| |
| ▲ | charcircuit a day ago | parent | prev | next [-] | | >This assumes that the operating system can run. So does being able to download a new version of software that uses different memory addresses. The point is if you are able to patch software, you are able to patch memory maps. | |
| ▲ | amluto a day ago | parent | prev | next [-] | | Oh, to be clear, I would not do this if I needed that degree of reliability. Or maybe I would use an MMU but drive it with a kernel written in the old fashioned way with no allocation. It would depend on what hardware I had available and what faults I wanted to survive. (I’m not an aerospace software developer.) | |
| ▲ | 5d41402abc4b 20 hours ago | parent | prev | next [-] | | >This assumes that the operating system can run. You could have two copies of the OS mapped to different memory regions. The CPU would boot with the first copy, if it fails watchdog would trigger and the CPU could try to boot the second copy. | |
| ▲ | d-lisp a day ago | parent | prev [-] | | Wow, but how did they deal with anomalies ? I mean, even when I have the codebase readily accessible and testable in front of my eyes, I never trust the tests to be enough ? I often spot forgotten edge cases and bugs of various sort in C/embedded projects BECAUSE I run the program, can debug and spot mem issues and whole a lot of other things for which you NEED to gather the most informations you can in order to find solutions ? |
|
|
