!RcWgvYgifDuhVmGsFl:matrix.org

SD-Development

32 Members
Enhancing spacedecentral.net and developing enabling technologies.1 Servers

You have reached the beginning of time (for this room).


Timestamp Message
11 Jul 2018
23:48:30@yalda:matrix.orgyalda changed the history visibility to "world_readable" from "shared".
13 Jul 2018
18:57:19@drbriefs:matrix.orgsean changed their display name from drbriefs to sean.
18:57:43@drbriefs:matrix.orgsean changed their profile picture.
23 Jul 2018
07:13:38@yalda:matrix.orgyalda changed the room name to "SD-Development" from "SD-Building Blocks".
07:18:42@yalda:matrix.orgyalda changed their profile picture.
24 Jul 2018
09:46:11@yalda:matrix.orgyalda 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/".
25 Jul 2018
13:18:50@mikro2nd:matrix.orgmikro2nd joined the room.
13:28:25@mikro2nd:matrix.orgmikro2nd set a profile picture.
31 Jul 2018
05:00:31@outbound:matrix.orgoutbound changed their profile picture.
1 Aug 2018
23:20:15@tmallard:matrix.orgtmallard joined the room.
2 Aug 2018
06:52:51@schorgie30:matrix.orgschorgie30 joined the room.
26 Aug 2018
00:00:51@drbriefs:matrix.orgsean invited @neutronstar:matrix.orgneutronstar.
04:33:58@neutronstar:matrix.orgneutronstar joined the room.
07:17:01@neutronstar:matrix.orgneutronstarDiscussions 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?
09:03:41@drbriefs:matrix.orgsean

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)!

19:15:49@neutronstar:matrix.orgneutronstarI'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?
20:30:13@drbriefs:matrix.orgsean

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!

6 Sep 2018
05:49:57@erikkulu:matrix.orgerik changed their display name from erikkulu to erik.
18 Sep 2018
19:03:30@neutronstar:matrix.orgneutronstarRealized 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:06:41@drbriefs:matrix.orgsean
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!
Care to repost for context?
19:10:26@neutronstar:matrix.orgneutronstar

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?

19:21:59@drbriefs:matrix.orgsean There's a MIL spec somewhere (I'll try and look for it) that's often referred to for qualifying space grade hardware. It might be overkill for our applications, but it might give us some set of constraints to work with.
19:55:13@neutronstar:matrix.orgneutronstar

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.

21 Sep 2018
14:32:17@mhpanda:matrix.orgmhpanda joined the room.
1 Oct 2018
20:04:21@danktron:matrix.orgdanktron joined the room.
12 Oct 2018
23:47:28@greg.g:matrix.orggreg.g joined the room.
19 Oct 2018
22:36:30@pete.b:matrix.orgpete.b joined the room.
16 Nov 2018
20:06:41@grouchofractal2:matrix.orggrouchofractal joined the room.
28 Nov 2018
15:31:24@theobtl:matrix.orgtheobtl joined the room.
12 Dec 2018
14:39:18@lkngtn:matrix.org@lkngtn:matrix.org left the room.

There are no newer messages yet.


Back to Room List