neutronstar: nothing that low-level as of yet, though you're more than welcome to get the conversation started! Are there any design constraints that come to mind that could help narrow down such options? I haven't had the luxury to investigate embedded level hardware or software options yet, but I'd imagine RAD750 may come up as a viable FCU solution, if/when we ever do such a trade study, considering it's NASA's current state of the art as far as space-grade flight computers go.

Regarding development process, at the highest level, we have the SMAP process, which is for selecting and defining high-level mission concepts (https://medium.com/spacedecentral/space-mission-activation-process-c6e7c2a0910f); on a systems engineering level, there're (WIP) plans to adopt an implementation of the model-based systems engineering methodology, using the Systems Modeling Language (SysML), which would serve as an interface between high-level mission & system level requirements and lower level system & software requirements, support verification & validation processes, lifecycle analysis, multi-disciplinary analysis & optimization (MDAO), and various other activities (see https://docs.google.com/presentation/d/1cvZYfUS3MYQZ0omOebTGaFulYbIOccHG89cxApIolCs/edit#); development process on the lowest-level (embedded) side is virtually non-existent at the moment, as we're still discussing whether the development of space-hardware itself should fall within the scope of the space decentral community - though, for context, we're also quite short staffed on systems engineers and embedded-hardware/software developers.

I should also mention a subset of the space decentral team are also working on blockchain apps that we plan on adopting as part of our platform to support governance and agile planning activities (https://medium.com/giveth/space-decentral-the-dao-for-space-exploration-2af372d310af). Last, but not least, there's of course the http://spacedecentral.net web platform itself, which is concurrently being enhanced alongside our other open-source projects.

My space decentral compadres can correct me or append to anything I may've missed, but hopefully that was descriptive or helpful enough (if not, please don't hesitate to ask more questions)!

My concern is how to map use cases to requirements, requirements to design/implementation requirements, and design/implementation requirements to actual code. Doing this manually doesn't work well in my experience, tools that tracks this automatically is needed. Would model based systems engineering help with this?

Yes, though at least that's what it intends. The most widely used implementation of the model-based systems engineering (MBSE) methodology is language called SysML, which is an extension of a subset of UML, which models systems into 3-5 "pillars" (depending on which source you consult):

1. Structure - Block diagrams, narrative descriptions of the elements of the system, and information on how the system interacts with users and external resources are examples of structure.
2. Behavior - contains descriptions of how the system should operate and how users should interact with it. User stories (use cases) and CONOPS are examples of behavior.
3. Requirements - formal requirements for the system.
4. Analysis - how to verify and validate the system as it is being developed. Descriptions of test cases and required scenarios/projects are examples of analysis
5. Verification & Validation - Validation is the process of checking whether the specification captures the customer's needs. “Did I build what I said I would?” (http://i0.kym-cdn.com/photos/images/original/000/475/749/fd8.jpg) Verification is the process of checking that the software/hardware meets the specification.

Without getting too much into detail, I've been working on a python implementation of SysML (see https://github.com/spacedecentral/SysML.py) to try and address shortcomings of the current MBSE tools. Reasons for why I chose python are outlined in the link above, but it would essentially be an interface for verifying and validating system requirements and their transcription to flight hardware/software - note: this use case is still a work-in-progress, so would love to get your feedback on the best way to implement this!

In reply to @neutronstar:matrix.org
Realized that my message in the mission room regarding what electronics to use should have been in this room, sorry for that. Feel free to comment my message here instead!

Ok, here is the repost:

Being an embedded developer, I couldn't resist the urge to look on what electronics that we might use. I've read up a bit on how to secure electronics against radiation and what electronics that might be bought off the shelf. After much consideration I've come to the conclusion that we can skip special radiation hardened electronics, except perhaps for some special smaller application. I would instead propose to use a number of smaller cheaper single board computers and use them in a voting and/or load balancing configuration. One suggestion below, costs 5$ each:

https://www.kickstarter.com/projects/onion/omega2-5-iot-computer-with-wi-fi-powered-by-linux

We need some I/O board to interface motors and sensors, and perhaps some voting hardware.

Any thoughts on this?

The problem with electronics adhering to military or space standards is not only costs, but also ITAR. This basically means no development outside USA for an open-source project, and even within USA there might be a bunch of rules to follow. A lot of hassle. Unless I've misunderstood something...

The exception would be if we found hardware from outside USA, but then it could be ITAR classified as soon as it reaches the borders.

So this is the reason I propose to use standard components. But we could of course improve it using good casing etc.