Sender | Message | Time |
---|---|---|
11 Jul 2018 | ||
stellarmagnet changed the history visibility to "world_readable" from "shared". | 23:48:30 | |
13 Jul 2018 | ||
sean changed their display name from drbriefs to sean. | 18:57:19 | |
sean changed their profile picture. | 18:57:43 | |
23 Jul 2018 | ||
stellarmagnet changed the room name to "SD-Development" from "SD-Building Blocks". | 07:13:38 | |
stellarmagnet changed their profile picture. | 07:18:42 | |
24 Jul 2018 | ||
stellarmagnet changed the room topic to "Enhancing spacedecentral.net and developing enabling technologies." from "Enhancing spacedecentral.net and developing enabling technologies. Contribute to program on https://github.com/spacedecentral/building-blocks/". | 09:46:11 | |
25 Jul 2018 | ||
@mikro2nd:matrix.org joined the room. | 13:18:50 | |
@mikro2nd:matrix.org set a profile picture. | 13:28:25 | |
31 Jul 2018 | ||
outbound changed their profile picture. | 05:00:31 | |
1 Aug 2018 | ||
tmallard joined the room. | 23:20:15 | |
2 Aug 2018 | ||
schorgie30 joined the room. | 06:52:51 | |
26 Aug 2018 | ||
sean invited neutronstar. | 00:00:51 | |
neutronstar joined the room. | 04:33:58 | |
neutronstar | Discussions in this room has so far centered around more high-level stuff, web-site and collaboration tools. I personally am a more low-level stuff. I'd love to get my hands dirty when it comes to software that will be in whatever we send into space/moon. Is there interest in discussions about choice of OS, how the development process should look like, how to manage use cases and requirements, how designs should be described and so on? | 07:17:01 |
sean | 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)! | 09:03:41 |
neutronstar | I'm not familiar with how model based systems engineering works, but I would love to learn more. I've heard about it before and it is one of those things that I have on my list that I should learn. I'll take a look at it. 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? | 19:15:49 |
sean |
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):
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! | 20:30:13 |
6 Sep 2018 | ||
erik changed their display name from erikkulu to erik. | 05:49:57 | |
18 Sep 2018 | ||
neutronstar | 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! | 19:03:30 |