Safety working group is back on!

Thanks to some recent new members who apparently have time to spare for the really fun stuff, the safety working group is starting up again. We’re taking a look at improving one of the fundamental parts of building safety-critical systems: tracing requirements to implementation and verification.

Check out our recent minutes to see what we’ve been talking about, and join in the next meeting if you’re interested! Our next meeting will be on 2020-05-28T14:00:00Z, and we meet every two weeks. You can find the meeting information in the ROS 2 events calendar and at the end of this email.



Join Zoom Meeting
https://zoom.us/j/266509195

Meeting ID: 266 509 195

One tap mobile
+19292056099,266509195# US (New York)
+16699006833,266509195# US (San Jose)

Dial by your location
+1 929 205 6099 US (New York)
+1 669 900 6833 US (San Jose)
+81 524 564 439 Japan
+81 3 4578 1488 Japan
+49 69 7104 9922 Germany
+49 30 3080 6188 Germany
+49 30 5679 5800 Germany
+34 917 873 431 Spain
+34 84 368 5025 Spain
+44 203 051 2874 United Kingdom
+44 203 481 5237 United Kingdom
+44 203 966 3809 United Kingdom
+44 131 460 1196 United Kingdom
Meeting ID: 266 509 195
Find your local number: https://zoom.us/u/ac1UM6kRuF

4 Likes

It would be super cool if the mtgs could be recorded, I’m very interested in keeping in the loop. :slight_smile:

Sure, I’ll see what I can do. The meetings will probably be shifting to Google Meet soon so I’ll need to test its recording feature.

To me it’s not clear at what you are aiming for with this meeting series. Is it about informing people how others implement RM? Is it about defining a unified way of enabling integration of ROS2 packages into RM tools?

BTW: I’ve no need to handle this super fun stuff right now but I’m happy to contribute w.r.t. past experiences I’ve made with various implementations of RM and their implications.

We’re still feeling our way forward ourselves, but one thing we are heading towards is producing or contributing to an open-source tool for requirements tracing that will make it easier to do some of the requirements tracing you need in software engineering in an open source project. This, in turn, may help those who want to take ROS and ROS-based software forward to a higher level of quality assurance and even certification. Or it might just make people focus their designs more. Either outcome is a plus.

3 Likes

Thanks for clarifying the thread purpose.

In the ROS2 component context system requirements are component requirements and system test requirements are component test requirements.

Some important features a RM tool needs to provide from ROS component user perspective:

  • As a ROS2 component user I want to be able to integrate the component RM artifacts (requirements, tests, links, etc.) into my own RM tool. Implication: Every tagged release of a ROS2 component should be shipped with requirements in an industry standard format. The only standard I know of is the Requirement Interchange Format. The specification can be found here: About the Requirements Interchange Format Specification Version 1.2.
  • As a ROS2 component user I want to be able to diff the RM artefacts (requirements, tests, links, etc.) of different versions of a ROS2 component I’m using in my overall system. Implication: The aim is to allow RM across the overall application lifecycle of the overall system. RM artifacts which turn out to be obsolete over time should not be deleted but marked as “archived” instead.

Some important features a RM tool needs to provide from ROS component developer perspective:

  • As a ROS2 component developer I want to be able to link a) one component requirement to one software requirement, b) several component requirements to one software requirement and c) one component requirement to several software requirements.
  • As a ROS2 component developer I want to be able to link a) one software requirement to one production code implementation (class/class method/function/etc.), b) several software requirements to one production code implementation and c) one software requirement to several production code implementation. Implication: The RM tool should provide corresponding command line interface commands. IDE extensions which integrate the RM tool with the IDE would allow to link RM artefacts in the most user friendly way.
  • As a ROS2 component developer I want to be able to get a) for every changed component requirement the linked software requirements and linked software implementations (impacted downstream artifacts), b) for every changed software requirement the linked component requirements (impacted upstream artifact) plus the linked software implementations (impacted downstream artifact) and c) for every changed production code implementation the linked software requirements plus linked component requirements (all upstream artifacts).

Some important features a RM tool needs to provide from ROS component tester perspective:

  • As a ROS2 component tester I want to be able to link a) one component test requirement to one software test requirement, b) several component test requirements to one software test requirement and c) one component test requirement to several software test requirements.
  • As a ROS2 component tester I want to be able to link a) one software test requirement to one software test implementation (test class/test class method/test function/etc.), b) several software test requirements to one test implementation and c) one test requirement to several test implementations.
  • As a ROS2 component tester I want to be able to get a) for every changed component test requirement the linked software test requirements and linked software test implementations (impacted downstream artifacts), b) for every changed software test requirement the linked component test requirements (impacted upstream artifact) plus the linked software test implementations (impacted downstream artifact) and c) for every changed test implementation the linked software test requirements plus linked component test requirements (all upstream artifacts).

Other open source RM tools not discussed so far:

Thanks for writing all that up.

To be honest, I don’t view RIF as a particularly viable format for our purposes (I have worked with it in the past). I think a format such as yaml is more suitable as it ensures ease-of-editing for even the most tool-stubborn, and my experience with using RIF in multiple tools has not been great. I won’t rule it out, though, if a good case for why it should be used can be made.

It is nice to follow a particular structure of requirement types, but given we are dealing entirely with software (and SEooC software at that), I think it is less essential - particularly in the differentiation between software requirements and other requirements.

Such reverse tracing is going to be the hardest part, probably.

As the maintainer of CAIRIS, I can elaborate a bit on the dependency on SQL databases. When CAIRIS is installed on a server, it does rely on mysql. However, CAIRIS models that users export are actually XML that conform to this DTD . Given that saving/opening CAIRIS models entails exporting/importing XML, adding support for exporting/importing ReqIF models seems do-able.
I might be open to adding this support if anyone wants to raise an issue and can make a good case :slight_smile:

You’re welcome.

I fully agree. In my opinion doorstep is the most lightweight and flexible alternative right now. With VSCode extensions it could be integrated into the dev workflows very well. However an export to reqif feature would be nice.

I agree. I don’t care about document content and structure. The relationship types (1-to-1, 1-to-many and many-to-1 even across different hierarchie Levels) are the thing to look for. But beeing able to define the structure of the generated document is even better. Both is supported by doorstop:

Such reverse tracing is going to be the hardest part, probably.

The scripting API should allow to implement something like this easily. Generation of a traceability matrix, dependency/impact analysis functionality could be implemented with/contributed to doorstop.

1 Like

doorstop allows to tag items (requirements) beeing “normative”. Propably it would make sense to request that one can be more specific about this with “functional safety” and “security” relevant items.

Yes, that’s a definite want.

Minutes for today’s meeting are now available:

The meeting recording is now available here.

1 Like

I put together a document outlining missing (and nice-to-have) features in Doorstop here: https://docs.google.com/document/d/1hXsuCAFy-6dasaGrb1zd93DUD9jWSNgfRFBFvsjQU8c/edit?usp=sharing

1 Like

I had a quick look at openfasttrace as well. Some initial thoughts:

  • Java-based and large repository. Built by Elektrobit
  • Focus appears to be on tracing, not formatting requirements documents (example output here). Supports tracing to multiple coding languages.
  • Tags based and more free-form than, say, Doorstop. Tags can appear anywhere in source or requirements tree. Not as document centric as Doorstop / classical tools.
    • Documents also do not need to be in YAML, could be “anything”
  • CLI output is less clear and probably harder to integrate with CI.
1 Like

Thanks for this summary. Nice to have would be additional CLI validation features (check if highest level requirements have at least one child requirement, check if highest level requirements have at least one linked test/verification artifact/item, check if non-highest level requirements have at least one linked parent requirement, etc.). If I remember correctly I emualted these checks in DOORS with some kind of filter functions. However this was not optimal cause one has to check the filtered items in DOORS manually. A CLI is way more powerful w.r.t. automatic these checks.

CAIRIS is really nice but in my opinion too heavyweight cause of it’s dependencies. However it’s jsust my point of view.

Once we have a basic CLI tool in place for use by CI it should be fairly easy to add new things to check for. As you say, this will allow us to automate a lot of the requirements tracing confirmation work.

Was the meeting cancelled today, or maybe the ROS Events calendar is out of date?