SD-Systems - Public Room Timeline

	SD-Systems	14 Members
	Systems Engineering riot room for Space Decentral	1 Servers

Load older messages

Sender	Message	Time
16 Dec 2018
outbound	Some thoughts. Thought #1 on uuid's: I've always seen an approach on the user side that is sort of a hybrid of mnemonic and uuid. You develop a document that has some sort of subsystem or functional prefix (MECH) and a unique requirement index number, say 0001. Until the document has been published, per se, the index number can be moved around. Once the document is published, the rule is that requirement prefix and index (MECH.0001) refers to the same requirement forever. If you want to update the requirements document, you certainly can, but you can't make one requirement number refer to an entirely new topic. Say MECH.0001 refers to "Coral must weigh no more than 10 lbs", you can't reword it to say "Coral must be painted bright green". Those are obviously two different topics. If you want to add a requirement on the paint color when revising a published req document, you would add a new number for it. Also, when you delete a requirement from a published req document, you can't reuse the number, you have retire it. In a sense, there is sort of a uuid kind of control within the req document itself in that way.	16:21:26
outbound	Thought #2 on Verification: In the requirement document, I've always had a table at the end that is a Verification Matrix. The first column is the unique req number, then three columns to the right, Inspection, Analysis, and Test. That allows you to just write the requirements and deal with how to verify it later. If you "bake in" the verification method into the requirement itself, that can be very constraining. Also, during design reviews, having the table allows for a step-by-step review of whether or not verification has been achieved. Also, from a uuid perspective, it's good to separate the verification of the requirement from the requirement itself.	16:32:31
outbound	Thought #3: I am used to seeing the subsystem prefix in all caps, because it makes references stand out as requirements, and for a specific subsystem. From the discussin above, I mean mech.0001 versus MECH.0001, the latter means specifically to refer to a Mechanism requirement, unmistakably. This is a preference on my part, so we can decide to keep it lower case if we must.	16:37:18
udit.kumar.sahoo	outbound: you read my mind. I agree to all your thoughts. 😄	16:42:03
neutronstar	Never reusing requirements ID is important. That the requirements ID has a logical structure or merely a sequence number or GitHub issue IDs is for me secondary. The later avoids discussions about whether a version number should be included, what happens with the name when a requirement is split or changed in a way that the name becomes misleading. But I also see benefits with logical requirements IDs since they become easier to reference without having to explain which requirement it is each time. So for me I can go both ways with that...	17:36:40
17 Dec 2018
neutronstar	I thought of another reason to use GitHub rather than a spreadsheet for requirements: It is possible to use GitHub data using GraphQL API. This would make it possible to create a client using this API. This means that the client could take care of presenting the requirements, use-cases etc in a nice way while using GitHub as a database for storing the requirements. This would make it easy to switch to another client if needed, or even use GitHub directly if you want. I'm not aware of any already written client for such a usage though, so we might have to write it whenever we need it... But I guess using GitHub directly will be fine for the time being.	10:06:36
neutronstar	I have now studied how GitHub issues work, and compared to what I'm used to (Jira) they are quite simplistic. This is a good thing for GitHub I would say, but when you want to do something more advanced like having use-cases and requirements in GitHub, the advantages become somewhat less obvious. Here is what I saw that could help organize the requirements: Labels - Could be used to set issue type, e.g. "Requirement", "Use case", "Regression test case" etc. Since multiple labels can be used, it can also be used to classify it in different ways, e.g. which system it applies on. Anything you would like to sort on which isn't provided by any of the built-in fields should be labels. Project - You can create one sub-project for each sub-system. This creates one issue range per sub-project. This also means that any reference need to be prefixed with the project name. I haven't made my mind up whether it is worth the extra administration, but I'm presenting the possibility in case someone thinks it's a great idea. Links - These are done in the issue description using #<name> references. This is the primitive part. There is no help assuring you get the links right and complete, so you need to rely on templates here. If we think that we will have less than a couple of hundred requirements and use-cases, the spreadsheet will most likely be easier to administrate. But if we get towards several hundred or even thousands, then the spreadsheet will be impossible to maintain. I'm guessing it will take a while before we reach that large number of requirements, so perhaps using a spreadsheet is a quick way to get something started...	19:18:31
udit.kumar.sahoo	Popular SysML/MBSE Modeling Tools \| A Listly List https://list.ly/list/23A-popular-sysml-modeling-tools	23:51:25
udit.kumar.sahoo	I have now studied how GitHub issues work, and compared to what I'm used to (Jira) they are quite simplistic. This is a good thing for GitHub I would say, but when you want to do something more advanced like having use-cases and requirements in GitHub, the advantages become somewhat less obvious. Here is what I saw that could help organize the requirements: Labels - Could be used to set issue type, e.g. "Requirement", "Use case", "Regression test case" etc. Since multiple labels can be used, it can also be used to classify it in different ways, e.g. which system it applies on. Anything you would like to sort on which isn't provided by any of the built-in fields should be labels. Project - You can create one sub-project for each sub-system. This creates one issue range per sub-project. This also means that any reference need to be prefixed with the project name. I haven't made my mind up whether it is worth the extra administration, but I'm presenting the possibility in case someone thinks it's a great idea. Links - These are done in the issue description using #<name> references. This is the primitive part. There is no help assuring you get the links right and complete, so you need to rely on templates here. If we think that we will have less than a couple of hundred requirements and use-cases, the spreadsheet will most likely be easier to administrate. But if we get towards several hundred or even thousands, then the spreadsheet will be impossible to maintain. I'm guessing it will take a while before we reach that large number of requirements, so perhaps using a spreadsheet is a quick way to get something started... This is a comprehensive analysis and appreciate your efforts @neutronstar:matrix.org	23:54:40
18 Dec 2018
sean	In reply to @udit.kumar.sahoo:matrix.org Popular SysML/MBSE Modeling Tools \| A Listly List https://list.ly/list/23A-popular-sysml-modeling-tools Another open source SysML/MBSE tool not on the list, currently maintained by NASA/JPL, is OpenMBEE http://www.openmbee.org/ It uses git-like version control called model-management system (MMS) for storing model information that can be accessed (via RESTAPI) using their View Editor (VE). They also have an example of a requirements table of the Thirty-meter telescope (TMT): https://mms.openmbee.org/alfresco/mmsapp/mms.html#/projects/PROJECT-39602c53-e22f-4069-b071-8340d908fb0f/master/documents/_18_5_1_baa02e2_1497194353067_602199_366099/views/_18_5_1_baa02e2_1497194262753_696891_244763 (username: `openmbeeguest`, password: `guest`) One caveat, of course, is that you need to connect to their MMS server, or run your own instance. It's also mostly designed to be used with their model-development kit (MDK) which is a plugin for MagicDraw, but in theory, users could still work out of the view editor.	02:05:03
sean	On a somewhat related note, if we want to start adopting ontologies for MBSE, JPL's Integrated model-centric environment (IMCE) project has a public repo for just that (granted, the documentation on how to use it isn't that great) https://github.com/JPL-IMCE/gov.nasa.jpl.imce.ontologies.public	02:09:22
suzi.bianco	Hi guys sorry I'm not joining in the discussions but this is way outside of my domain... Buy I do have a question: are we talking about keeping all of these hundreds of requirements in the same github repo as our regular tasks? Won't that become overly confusing?	02:21:05
sean	Hi guys sorry I'm not joining in the discussions but this is way outside of my domain... Buy I do have a question: are we talking about keeping all of these hundreds of requirements in the same github repo as our regular tasks? Won't that become overly confusing? I'm assuming "in the same github repo" is referring to the github issues and not the repo itself. In which case, valid question/concern 🙂	02:31:17
suzi.bianco	Right that's what I meant, now I don't know if that's what you all meant before 🤪	02:32:22
udit.kumar.sahoo	No not yet. We are still WIP	03:06:36
19 Dec 2018
Patrick Donovan	any suggestions or preferences for streamlining Coral's Google Drive folder? I have some ideas but don't want to inflict my will upon it quite yet	05:11:04
udit.kumar.sahoo	Share your thoughts @Patrick Donovan . We'll discuss whether it needs modification.	06:20:14
20 Dec 2018
	tmallard joined the room.	02:23:46
Patrick Donovan	In reply to @udit.kumar.sahoo:matrix.org Share your thoughts @Patrick Donovan . We'll discuss whether it needs modification. sure thing. the ideas aren't mutually exclusive. without further ado: idea #1 is dependent on the nomenclature debate being settled and rigorously enforced. The general idea is that prudent file naming can reduce the amount of nested folders while making things actually easier to find (according to the internet). idea #2: for now, remove the distinction between "program" and "pre-phase A" in the Drive files and folders	03:32:51
neutronstar	suzi.bianco: Having hundreds of requirements in GitHub is not a problem, as long as you have a working labeling system. But hundreds might sound a lot, but when you start thinking of how many sub-systems you have, stakeholders and so on you will soon realize that it isn't all that much. So the problem really is that we sooner or later will approach many hundreds or even thousands. That's when it will become a challenge storing them on GitHub. So your concern is still valid. But my point was merely that this problem is worse using a spreadsheet. On a spreadsheet my experience is that the maintenance nightmare starts somewhere around a couple of hundreds. Others might have other experiences with it, just saying what mine are. I haven't looked at the tools suggested by other people above, I'll see if I can allocate some time to do so. I think in the end having a good tool for handling requirements is most likely the best solution.	08:36:11
suzi.bianco	My thought was: to have one github for actual tasks, derived from the wbs, and another for the requirements?	15:56:15
sean	> My thought was: to have one github for actual tasks, derived from the wbs, and another for the requirements? We could pull a page from the Python community and designate one repo for requirements proposals, much like PEPs (Python enhancement proposals), where each github issue links to a proposal (in our case, for a requirement) - wherein proposals that pass the vetting process would get merged into the master branch. https://github.com/python/peps	16:17:38
tmallard	Found this on payload CPU, Xilinx PGFA "Peregrine’s flight computer serves as the spacecraft’s brain and consists of a 32-bit high-performance dual-core microprocessor. The computer employs radiation-hardened integrated circuits as well as fault-tolerant and SEU-proof characteristics. The payload controller is also housed within the IAU and manages the individual payloads as well as their contractual services. The payload controller features Error Detection And Correction (EDAC), upset monitoring, and software robustness. The LEON flight computer board Flight CPU Design: Payload CPU Design: Payload CPU Safety Features: LEON 3 FT Xilinx FPGA EDAC, Software Robustness"	22:13:08
21 Dec 2018
neutronstar	All radiation hardened hardware I've found on the Internet so far has had ITAR restrictions, but if anyone finds something without ITAR restrictions I would love to hear about it.	04:06:30
tmallard	neutronstar ... a reaction that a neoprene is used for rad, and, good old polyethylene pretty good, "1 cm lead reduces dose by almost the same percentage as 1 cm polyethylene, but with a much greater mass penalty.", seems cheap thrills on rad vs other means.	17:05:40
udit.kumar.sahoo	Guys we may be going off topic on this group. Let's stick only to systems here please.	17:29:21
sean	^ditto	17:37:13
neutronstar	@udit.kumar.sahoo:matrix.org: Oops, you're right, let's continue the discussion in SD-development.	18:05:58
28 Dec 2018
udit.kumar.sahoo	I may be knocking during holiday season, but I thought this is necessary to discuss. After, considering all the discussion above, I went down hunting for the right tool (free to use and supports most of our activities). After considering, Modellio, Papyrus and Capella; I think we should use capella for our activities. I'm putting the link below for your reference. Also, I will try to model what we have as an operational concept.	14:29:42
udit.kumar.sahoo	https://www.polarsys.org/capella/arcadia.html	14:29:45

Show newer messages

Back to Room ListRoom Version: 1