[00:00.000 --> 00:09.000]  So, next up, Nicole.
[00:09.000 --> 00:12.000]  So, yeah.
[00:12.000 --> 00:14.000]  Okay.
[00:14.000 --> 00:16.000]  Hi, everyone.
[00:16.000 --> 00:18.000]  Hi, everyone at home.
[00:18.000 --> 00:24.000]  So, yeah, I'm talking today about how to maybe use SPDX to
[00:24.000 --> 00:27.000]  establish traceability for functional safety.
[00:27.000 --> 00:32.000]  So, about me, yeah, I've been a software developer for quite some time,
[00:32.000 --> 00:37.000]  always working in, yeah, some kind of safety-critical project,
[00:37.000 --> 00:40.000]  and that somehow brought me about 12 years ago to, yeah,
[00:40.000 --> 00:45.000]  really focusing on functional safety.
[00:45.000 --> 00:50.000]  And so, currently, I'm working as a tech consultant still, yeah,
[00:50.000 --> 00:52.000]  mainly in functional safety, a little bit security,
[00:52.000 --> 00:54.000]  a little bit license compliance.
[00:54.000 --> 00:58.000]  That gets critical for software components.
[00:58.000 --> 01:03.000]  I'm involved in some of the Linux Foundation projects.
[01:03.000 --> 01:06.000]  And, yeah, just important thing about me,
[01:06.000 --> 01:08.000]  I'm really not good with faces and names.
[01:08.000 --> 01:12.000]  So, if you walk past by me and I don't say hello,
[01:12.000 --> 01:15.000]  it's just because I'm not really sure if it's you.
[01:15.000 --> 01:19.000]  So, just say hello to me and, yeah, then I know it's you.
[01:19.000 --> 01:24.000]  And you can contact me, or usually with a handle at Nick Pappler
[01:24.000 --> 01:29.000]  at the usual social media or GitHub places if you want to find me.
[01:29.000 --> 01:35.000]  So, what can we do for functional safety with SPDX?
[01:35.000 --> 01:40.000]  So, I'm not sure who at all here is aware about functional safety
[01:40.000 --> 01:43.000]  or what it is.
[01:43.000 --> 01:45.000]  Oh, a few, that's cool.
[01:45.000 --> 01:47.000]  So, yeah.
[01:47.000 --> 01:49.000]  It's more than a thought.
[01:49.000 --> 01:51.000]  So, I'm happy.
[01:51.000 --> 01:56.000]  So, yeah, safety, generally, it's a freedom of risk
[01:56.000 --> 02:02.000]  or a minimization of risk of getting hurt, of doing something bad.
[02:02.000 --> 02:09.000]  And the functional safety part of that is that whatever can break
[02:09.000 --> 02:13.000]  or go wrong in your system is handled, is detected.
[02:13.000 --> 02:16.000]  So, you have mainly two options here.
[02:16.000 --> 02:19.000]  Avoid something bad to happen.
[02:19.000 --> 02:22.000]  Avoid the microcontroller to break.
[02:22.000 --> 02:27.000]  Avoid your software to do something you haven't intended it to do.
[02:27.000 --> 02:31.000]  Or, at least, to detect things going wrong
[02:31.000 --> 02:35.000]  and then define, initiate mitigation measures,
[02:35.000 --> 02:38.000]  define safe states, so what to do when things go wrong
[02:38.000 --> 02:43.000]  and implement this and hopefully have a safe system at the end.
[02:43.000 --> 02:46.000]  So, what do we need if we want to do this?
[02:46.000 --> 02:51.000]  So, as I already said, you need a system that's robust
[02:51.000 --> 02:55.000]  and suitable for your safety application
[02:55.000 --> 02:59.000]  so that it in itself has some features that it doesn't kill people,
[02:59.000 --> 03:02.000]  that it doesn't hurt people, that it doesn't hurt the environment
[03:02.000 --> 03:07.000]  and several levels of analyzers, of tests, of verification measures
[03:07.000 --> 03:12.000]  to prove that your system is your system as you have intended it to be.
[03:12.000 --> 03:16.000]  And to do so, to really make sure what you have specified,
[03:16.000 --> 03:19.000]  you have implemented in the end, you should have a process,
[03:19.000 --> 03:21.000]  you should have guidelines, methods,
[03:21.000 --> 03:25.000]  and you should plan how to do this.
[03:25.000 --> 03:30.000]  And, unfortunately, this results in a lot of documents.
[03:30.000 --> 03:33.000]  You usually start with something called a safety plan,
[03:33.000 --> 03:35.000]  so it's kind of project management plan
[03:35.000 --> 03:39.000]  or any kind of plan strategy, how you want to do this.
[03:39.000 --> 03:41.000]  It's a plan, how you want to verify with this,
[03:41.000 --> 03:44.000]  you have your requirements, you have an architecture,
[03:44.000 --> 03:49.000]  go coding guidelines, you have loads of documents,
[03:49.000 --> 03:55.000]  50 to 100 documents in the end, so it's really, it's a pain.
[03:55.000 --> 03:59.000]  So, and I think most of us here are engineers
[04:00.000 --> 04:03.000]  and, yeah, engineers like to engineer.
[04:03.000 --> 04:07.000]  And so, we like to create it with a fantastic system,
[04:07.000 --> 04:10.000]  maintaining a fantastic system.
[04:10.000 --> 04:14.000]  Yeah, we do have to do, at least in the industry life,
[04:14.000 --> 04:18.000]  apply a process to do so, and then we have to ensure
[04:18.000 --> 04:20.000]  there is all documentation in place
[04:20.000 --> 04:22.000]  and all evidences are consistent.
[04:22.000 --> 04:25.000]  So, yeah, first two things we really like to do,
[04:25.000 --> 04:27.000]  we like to create things, we like to maintain things,
[04:27.000 --> 04:29.000]  we like to have them fantastic.
[04:29.000 --> 04:32.000]  Applying a process, yeah, if we have to,
[04:32.000 --> 04:37.000]  some like me like processes, but I think 99% don't.
[04:37.000 --> 04:41.000]  And, yeah, ensuring all documentation and evidences
[04:41.000 --> 04:44.000]  are consistent, that's, at least for most engineers,
[04:44.000 --> 04:47.000]  it's no, no, you don't like this, this is pain,
[04:47.000 --> 04:50.000]  this is, at least emotionally, that feels like
[04:50.000 --> 04:52.000]  it's something I have to do on top because I know
[04:52.000 --> 04:54.000]  what I did, I know what I want to do,
[04:54.000 --> 04:57.000]  why do I need to record this, it's clear.
[04:58.000 --> 05:03.000]  So, just if we assume the process to create
[05:03.000 --> 05:05.000]  and maintain all artifacts that you need for functional
[05:05.000 --> 05:08.000]  safety of the plants, the requirements,
[05:08.000 --> 05:12.000]  the verification evidences, they, it's established
[05:12.000 --> 05:15.000]  and you will do this, but you still have the biggest pain
[05:15.000 --> 05:19.000]  there, keeping it complete and keeping it consistent
[05:19.000 --> 05:23.000]  during all the time for all your variants,
[05:23.000 --> 05:25.000]  during all your patches.
[05:26.000 --> 05:30.000]  So, the idea was then, hey, why can't we use
[05:30.000 --> 05:33.000]  SPDX-style solution there where you have the full
[05:33.000 --> 05:36.000]  traceability of a safety package or whatever
[05:36.000 --> 05:40.000]  to track all your possible combinations of your system.
[05:42.000 --> 05:46.000]  And, there is something in SPDX called relationships
[05:46.000 --> 05:49.000]  and these relationships actually, when you look
[05:49.000 --> 05:54.000]  into them, describe exactly what we do in functional
[05:54.000 --> 05:56.000]  safety with the idea of traceability.
[05:56.000 --> 05:58.000]  So, really traceability, this belongs to that
[05:58.000 --> 06:01.000]  and that version and it goes into that and it's
[06:01.000 --> 06:03.000]  created according to that.
[06:03.000 --> 06:06.000]  So, actually, when you look into the relationships list,
[06:06.000 --> 06:09.000]  at least nearly everything that you need is there.
[06:10.000 --> 06:13.000]  So, how could these relationships then really work
[06:13.000 --> 06:14.000]  for functional safety?
[06:14.000 --> 06:18.000]  So, FUSA is Geeks speak for functional safety,
[06:18.000 --> 06:20.000]  Geeks speak for functional safety.
[06:21.000 --> 06:24.000]  So, the documentation structure for functional
[06:24.000 --> 06:27.000]  safety usually consists of three types of documents.
[06:27.000 --> 06:30.000]  On the one hand side, you have all your plans,
[06:30.000 --> 06:32.000]  your processes, your guidelines, your strategy,
[06:32.000 --> 06:35.000]  how to do things, then you have your requirements
[06:35.000 --> 06:39.000]  and specifications saying, okay, what have we done
[06:39.000 --> 06:44.000]  or what do we plan to do from technical point of view
[06:44.000 --> 06:47.000]  and you have all your verification evidences,
[06:47.000 --> 06:51.000]  your safety analyzes, your STPA tests, test cases,
[06:51.000 --> 06:54.000]  reports, any kind of evidence in the end.
[06:56.000 --> 06:59.000]  And, yeah, we are that old, we like the V-Model
[06:59.000 --> 07:01.000]  from functional safety point of view.
[07:01.000 --> 07:03.000]  At least we want to try to have something
[07:03.000 --> 07:06.000]  that is understandable by people who like the V-Model.
[07:07.000 --> 07:11.000]  So, any kind of documentation of work products,
[07:11.000 --> 07:14.000]  of artifacts that we have usually fits into this V-Model.
[07:14.000 --> 07:17.000]  So, we have the requirements, we have the full workflow,
[07:17.000 --> 07:22.000]  we have tests associated with requirement style information,
[07:22.000 --> 07:25.000]  we have reports that document that we did this test
[07:25.000 --> 07:28.000]  and the outcome of the test and we have all these documents
[07:28.000 --> 07:32.000]  that are associated with the processes, the plans,
[07:33.000 --> 07:38.000]  the guidelines, yeah, how to qualify things,
[07:39.000 --> 07:41.000]  how to assess stuff in the end.
[07:41.000 --> 07:43.000]  So, we have everything in plans,
[07:43.000 --> 07:47.000]  we have everything in the V-Model and as you see,
[07:47.000 --> 07:52.000]  the documents are some kind of interconnected.
[07:52.000 --> 07:56.000]  So, when we speak from the functional safety point of view,
[07:56.000 --> 08:01.000]  what are plans, processes and guidelines,
[08:01.000 --> 08:03.000]  what are they, what's that kind of document
[08:03.000 --> 08:06.000]  and in actually, it's just kind of artifact
[08:06.000 --> 08:09.000]  that specifies something, it specifies how to do things,
[08:09.000 --> 08:13.000]  how you plan to do things, how another document
[08:13.000 --> 08:16.000]  or another artifact should be structured or created.
[08:16.000 --> 08:18.000]  So, it's always a specification.
[08:18.000 --> 08:21.000]  So, when we look into standard safety document,
[08:21.000 --> 08:23.000]  the safety plan.
[08:23.000 --> 08:26.000]  Safety plan itself, it's just a specification
[08:26.000 --> 08:29.000]  how to do safety in the project or for the product.
[08:29.000 --> 08:32.000]  The coding guidelines, it's a specification
[08:32.000 --> 08:35.000]  how to create the code.
[08:35.000 --> 08:37.000]  So, it's always a specification,
[08:37.000 --> 08:40.000]  a plan is always a specification how to do things.
[08:41.000 --> 08:44.000]  Then, when we look into the product documentation,
[08:44.000 --> 08:47.000]  yeah, what kind of product documentation
[08:47.000 --> 08:49.000]  will we need to manage or do we have
[08:49.000 --> 08:51.000]  in our functional safety project?
[08:51.000 --> 08:55.000]  We have requirements, we have report type documents,
[08:55.000 --> 08:58.000]  test results, some analysis results
[08:58.000 --> 09:00.000]  and we have the code.
[09:01.000 --> 09:06.000]  And when we look into the product style documentation,
[09:06.000 --> 09:09.000]  it's a little bit more complex than plans.
[09:09.000 --> 09:12.000]  So, yeah, a safety requirement specification clearly,
[09:12.000 --> 09:15.000]  it's a specification of the safety requirements
[09:15.000 --> 09:18.000]  of what you want to achieve from a safety point of view.
[09:18.000 --> 09:23.000]  A unit test is a test case related to a specification part
[09:23.000 --> 09:25.000]  or to a part of code.
[09:26.000 --> 09:28.000]  The unit test report itself, then,
[09:28.000 --> 09:30.000]  is a documentation of the test case again.
[09:32.000 --> 09:36.000]  So, yeah, and as you see, everything is connected,
[09:36.000 --> 09:39.000]  everything can be expressed with a relationship.
[09:40.000 --> 09:44.000]  And, yeah, I'm working in functional safety
[09:44.000 --> 09:46.000]  for quite some time and I always say
[09:46.000 --> 09:48.000]  it's about a safe product, it's not about assessments,
[09:48.000 --> 09:50.000]  it's not about standards.
[09:50.000 --> 09:53.000]  But yeah, the only present question always is,
[09:53.000 --> 09:55.000]  what do I need for the assessment?
[09:55.000 --> 09:57.000]  How can I make my assessor happy in the end?
[09:57.000 --> 10:00.000]  So, as I say, you have to have a safe product
[10:00.000 --> 10:02.000]  and they say I want to make my assessor happy.
[10:02.000 --> 10:05.000]  So, what do you need to make your assessor happy?
[10:05.000 --> 10:08.000]  Yeah, to begin with, they will ask you
[10:08.000 --> 10:10.000]  for a lot of planning documents.
[10:10.000 --> 10:13.000]  The safety plan, a product architecture
[10:13.000 --> 10:17.000]  or your design, a strategy, how you want to do things
[10:17.000 --> 10:21.000]  so really that they have in the beginning an idea.
[10:21.000 --> 10:23.000]  What's in the scope? What do you plan to do?
[10:23.000 --> 10:26.000]  Do you have at all an idea of what you want to do?
[10:27.000 --> 10:34.000]  Then, yeah, the concept you show then should be sound,
[10:34.000 --> 10:37.000]  should be safe, at least you should have an idea
[10:37.000 --> 10:39.000]  at the beginning and you should have an idea
[10:39.000 --> 10:43.000]  about the completeness and consistency of your plans
[10:43.000 --> 10:47.000]  and in the end really present everything
[10:48.000 --> 10:53.000]  as a consistent, complete and, yeah, full product.
[10:58.000 --> 11:01.000]  So, when we look into this, it's always, again,
[11:01.000 --> 11:06.000]  it's related documents and from the assessment point of view
[11:06.000 --> 11:10.000]  it's a package and the package is described by a list.
[11:10.000 --> 11:13.000]  So, you always have lists of documents,
[11:13.000 --> 11:17.000]  okay, in this point of time, dear assessor
[11:17.000 --> 11:20.000]  or dear internally QM department,
[11:20.000 --> 11:23.000]  we have this part of information and we start from there
[11:23.000 --> 11:27.000]  and then later you have more information
[11:27.000 --> 11:31.000]  and say, okay, I have a new package and you get this one
[11:31.000 --> 11:33.000]  and in the end you have the full package
[11:33.000 --> 11:37.000]  and you have all your reports, all your configuration,
[11:37.000 --> 11:41.000]  all your calibrations and you will deliver that one.
[11:44.000 --> 11:46.000]  And actually, when we look into this
[11:46.000 --> 11:48.000]  from the SPDX point of view, yeah,
[11:48.000 --> 11:52.000]  it's all information that you can use to generate S-bombs
[11:52.000 --> 11:56.000]  for safety or we call them now safety S-bombs
[11:56.000 --> 12:00.000]  to really support your safety compliance argumentation
[12:00.000 --> 12:03.000]  and to really deliver the information always
[12:03.000 --> 12:07.000]  what is in the product, what is in the scope.
[12:07.000 --> 12:12.000]  So, how can I use this maybe in detail?
[12:12.000 --> 12:15.000]  So, as I said before, usually when you start an assessment,
[12:15.000 --> 12:17.000]  you start with a concept assessment,
[12:17.000 --> 12:20.000]  so what's the plan, what's the scope of the product,
[12:20.000 --> 12:22.000]  what's the safety scope of the product,
[12:22.000 --> 12:24.000]  what's maybe the beginning architecture
[12:24.000 --> 12:26.000]  and how do you plan to do things.
[12:26.000 --> 12:28.000]  Then you have a final assessment saying,
[12:28.000 --> 12:30.000]  okay, we are ready now.
[12:30.000 --> 12:33.000]  We want to get a final safety approval.
[12:33.000 --> 12:36.000]  We are really sure that we have a great product
[12:36.000 --> 12:38.000]  and we want to ship this.
[12:39.000 --> 12:43.000]  And as a real life is, you will have reassessments
[12:43.000 --> 12:46.000]  because your product is involving,
[12:46.000 --> 12:50.000]  you have CVs and all that stuff.
[12:50.000 --> 12:53.000]  So, what do we really need?
[12:53.000 --> 12:57.000]  So, as I said again, concept assessment has a goal
[12:57.000 --> 13:01.000]  that you have a proof that your concept is sound,
[13:01.000 --> 13:05.000]  that you can generally start working like that.
[13:05.000 --> 13:09.000]  So, you have your safety plan, any other initial plans
[13:09.000 --> 13:12.000]  where you set up how to do things,
[13:12.000 --> 13:14.000]  you'll have a safety concept.
[13:14.000 --> 13:18.000]  So, yeah, you will have a package of information,
[13:18.000 --> 13:21.000]  you will have a list of things that you want to deliver.
[13:21.000 --> 13:24.000]  So, when we look into the S-Bomb types
[13:24.000 --> 13:27.000]  that we heard about in the morning today,
[13:27.000 --> 13:30.000]  it's actually nothing else than a design S-Bomb.
[13:30.000 --> 13:32.000]  It's how to do things.
[13:32.000 --> 13:35.000]  Now, you can think about this like when you build a house,
[13:35.000 --> 13:37.000]  it's like the plan.
[13:40.000 --> 13:43.000]  The plan, how to build a house,
[13:43.000 --> 13:49.000]  it's what will be the methods you use,
[13:49.000 --> 13:53.000]  will it be in stone, who will come to do this,
[13:53.000 --> 13:57.000]  will you need certain machinery, something like that.
[13:58.000 --> 14:05.000]  Then, what?
[14:10.000 --> 14:13.000]  Okay, oh yeah, that was it, sorry.
[14:13.000 --> 14:19.000]  Then, the next stage really is go through your assessment stages.
[14:19.000 --> 14:21.000]  So, yeah, you have your concept ready
[14:21.000 --> 14:27.000]  and you won't have all the things ready
[14:27.000 --> 14:31.000]  and then ship them without some milestones in between.
[14:31.000 --> 14:36.000]  So, for each milestone, you will have a package of things,
[14:36.000 --> 14:39.000]  you will have a list of things that are not really built
[14:39.000 --> 14:42.000]  into a final product, but that are, yeah,
[14:42.000 --> 14:47.000]  somehow sources of information for what you have done so far.
[14:48.000 --> 14:52.000]  So, yeah, you could, for example, use the source S-Bomb for that,
[14:52.000 --> 14:55.000]  really as a list of all documents
[14:55.000 --> 14:58.000]  that will be part of your product up to then.
[15:00.000 --> 15:04.000]  Then, final stage is, yeah, you have finally everything
[15:04.000 --> 15:08.000]  that you want to have in your product and you start testing.
[15:08.000 --> 15:12.000]  And so, you have really all your plans,
[15:12.000 --> 15:15.000]  you have all your specifications, you have all your test cases,
[15:15.000 --> 15:19.000]  you most probably will have all your test reports
[15:19.000 --> 15:23.000]  and you will deploy this and see if it runs the first time.
[15:23.000 --> 15:26.000]  So, yeah, it's the first build that you have of your product.
[15:26.000 --> 15:30.000]  So, you can ship a build S-Bomb with completely everything
[15:30.000 --> 15:34.000]  that you need for the product, for the testing of the product.
[15:34.000 --> 15:38.000]  And then, when we look into final things,
[15:38.000 --> 15:43.000]  this is when things become tricky because, yeah,
[15:43.000 --> 15:48.000]  I come from the automotive world, yeah, you have one software build
[15:48.000 --> 15:52.000]  and then you have a bunch of calibration and configuration data
[15:52.000 --> 15:57.000]  that goes with your software into the vehicle,
[15:57.000 --> 16:01.000]  that goes on the road or into several types of vehicles.
[16:01.000 --> 16:04.000]  So, you have then really a different set of configuration
[16:04.000 --> 16:08.000]  and calibration data going with your release
[16:08.000 --> 16:13.000]  and that's really getting into the question
[16:13.000 --> 16:16.000]  what is really deployed on your system.
[16:16.000 --> 16:19.000]  So, because you have your runnable and you have your configuration data
[16:19.000 --> 16:22.000]  and you have a bunch of versions of that
[16:22.000 --> 16:28.000]  and it's really hard, honestly speaking, to keep track of this.
[16:28.000 --> 16:32.000]  So, here, this deployed S-Bomb would really come into handy,
[16:32.000 --> 16:37.000]  say, okay, we have everything and we know with a generated list
[16:37.000 --> 16:41.000]  what's really deployed on this vehicle.
[16:41.000 --> 16:47.000]  So, the real beauty, what I really see in this approach
[16:47.000 --> 16:52.000]  is that you can really close the loop about what you want to have
[16:52.000 --> 16:54.000]  and what you have in the end.
[16:54.000 --> 16:59.000]  So, standard in safety development is, yeah,
[16:59.000 --> 17:01.000]  you have the configuration management plan saying,
[17:01.000 --> 17:05.000]  okay, what types of documents do you have,
[17:05.000 --> 17:08.000]  what do you want to do then, how do you want the versions
[17:08.000 --> 17:12.000]  and what are baselines and branching and all that stuff
[17:12.000 --> 17:17.000]  and you have a list of documents that you plan to have.
[17:17.000 --> 17:21.000]  So, that's really, yeah, it's called configuration item list
[17:21.000 --> 17:23.000]  in the most projects.
[17:23.000 --> 17:26.000]  It's really the list starting from the safety plan
[17:26.000 --> 17:29.000]  down to each source file that you have.
[17:29.000 --> 17:32.000]  But in the end, again, you will compile this
[17:32.000 --> 17:35.000]  in what you really have in the end,
[17:35.000 --> 17:37.000]  and that's usually then in the safety world,
[17:37.000 --> 17:38.000]  it's the safety case.
[17:38.000 --> 17:43.000]  So, really, a compilation of all safety evidence that you have.
[17:43.000 --> 17:47.000]  In most cases, it's a copy of the configuration item list
[17:47.000 --> 17:49.000]  with all information attached,
[17:49.000 --> 17:52.000]  what's the final and valid version
[17:52.000 --> 17:56.000]  of this configuration item list member
[17:56.000 --> 17:59.000]  that goes into the final release.
[18:00.000 --> 18:04.000]  And in, yeah, most cases that I see,
[18:04.000 --> 18:07.000]  this is a manual process.
[18:07.000 --> 18:10.000]  Partially, they might generate something,
[18:10.000 --> 18:13.000]  but there's a lot of manual stuff in there.
[18:13.000 --> 18:17.000]  And then, yeah, comes the assessment type.
[18:17.000 --> 18:22.000]  You need to really make sure that everything
[18:22.000 --> 18:24.000]  that's in the safety case or everything
[18:24.000 --> 18:26.000]  that's in the configuration item list
[18:26.000 --> 18:28.000]  really goes into the safety case and that it's consistent
[18:28.000 --> 18:29.000]  and all that stuff.
[18:29.000 --> 18:32.000]  And usually, this is really done in manual spot checks.
[18:32.000 --> 18:36.000]  So, it's a pain and it's error-prone
[18:36.000 --> 18:39.000]  because spot checks will just give you a picture
[18:39.000 --> 18:43.000]  of how you can, yeah, there's just so far
[18:43.000 --> 18:45.000]  you can go with spot checks.
[18:45.000 --> 18:50.000]  So, the idea here, oops, there's a typo.
[18:50.000 --> 18:54.000]  The idea here is really that you have your generated
[18:54.000 --> 18:57.000]  S-bomb with everything that is deployed
[18:57.000 --> 19:00.000]  and you can then automatically more or less check back,
[19:00.000 --> 19:04.000]  is everything that I have in my generated S-bomb
[19:04.000 --> 19:06.000]  from the configuration item list,
[19:06.000 --> 19:09.000]  do I have some open ends in my relationships?
[19:09.000 --> 19:12.000]  Because if I have open ends, there might be,
[19:12.000 --> 19:15.000]  there will be some gap in what I have,
[19:15.000 --> 19:18.000]  maybe not tested, not verified,
[19:18.000 --> 19:21.000]  or just not thought about, maybe in my analyzers.
[19:21.000 --> 19:23.000]  So, you will see the open ends.
[19:23.000 --> 19:28.000]  You will see that there are things that might not match.
[19:28.000 --> 19:30.000]  And the next beauty is, yeah,
[19:30.000 --> 19:34.000]  you can do this process manually as often as you want to,
[19:34.000 --> 19:37.000]  but it is a pain and it takes time.
[19:37.000 --> 19:39.000]  And it is error-prone and it needs a human
[19:39.000 --> 19:43.000]  and it needs a lot of ex-lists, PDFs, whatever.
[19:43.000 --> 19:46.000]  It's a pain, it's hard to document,
[19:46.000 --> 19:48.000]  it's hard to keep track with it.
[19:48.000 --> 19:52.000]  And it's not like, yeah, what we had maybe 10 years ago
[19:52.000 --> 19:55.000]  you release once a year and maybe you have a patch
[19:55.000 --> 19:58.000]  every three months if you're really into patches.
[19:58.000 --> 20:01.000]  You have CVs coming in, you have continuous integration,
[20:01.000 --> 20:04.000]  you have bugs, you have product variants,
[20:04.000 --> 20:07.000]  and doing this loop all the time manually,
[20:07.000 --> 20:11.000]  you won't be able to, you are not able to keep track of it.
[20:11.000 --> 20:13.000]  And that's one of the biggest issues
[20:13.000 --> 20:15.000]  in the safety world at the moment.
[20:15.000 --> 20:19.000]  How can we have changes due to the CVs,
[20:19.000 --> 20:22.000]  due to the security things that we need to implement,
[20:22.000 --> 20:24.000]  we need to update.
[20:24.000 --> 20:26.000]  We can't say, oh, we have a safety certification,
[20:26.000 --> 20:30.000]  we cannot update, we cannot direct to security issues.
[20:30.000 --> 20:32.000]  That's just not possible.
[20:32.000 --> 20:38.000]  And so the idea here is, as long as you have your bomb,
[20:38.000 --> 20:42.000]  your S-bomb, your safety bomb, whatever you want to call it,
[20:42.000 --> 20:45.000]  of really all your documents in the configurations
[20:45.000 --> 20:47.000]  that you have in the end,
[20:47.000 --> 20:49.000]  then you can automatically scan again,
[20:49.000 --> 20:52.000]  do I have this, where do I need to change things,
[20:52.000 --> 20:55.000]  change things, have this run again,
[20:55.000 --> 20:57.000]  and see if you're still complete.
[20:57.000 --> 21:00.000]  So, yeah, that's the idea.
[21:00.000 --> 21:03.000]  So we started with this idea about, yeah,
[21:03.000 --> 21:06.000]  I think maybe half a year ago.
[21:06.000 --> 21:09.000]  So there are still a lot of open topics.
[21:09.000 --> 21:11.000]  It's details about how to set up the tooling,
[21:11.000 --> 21:13.000]  what tooling to use, what do we need,
[21:13.000 --> 21:16.000]  what is there, how can I do this.
[21:16.000 --> 21:18.000]  Then the full relationship model
[21:18.000 --> 21:20.000]  between the safety artifacts.
[21:20.000 --> 21:23.000]  It's also ongoing.
[21:23.000 --> 21:27.000]  A complete model about document and evident types.
[21:27.000 --> 21:29.000]  So we do have document types,
[21:29.000 --> 21:32.000]  but is it sufficient what we currently see?
[21:32.000 --> 21:36.000]  Then we want to have a pilot project as proof of concept.
[21:36.000 --> 21:39.000]  Yeah, that's candidates for that.
[21:39.000 --> 21:41.000]  And yeah, I'm from the safety world.
[21:41.000 --> 21:45.000]  I speak safety, compliance, standards.
[21:45.000 --> 21:48.000]  But there are security standards,
[21:48.000 --> 21:50.000]  for example, around other standards
[21:50.000 --> 21:52.000]  that ask for this compliance information.
[21:52.000 --> 21:56.000]  There's now, in the automotive, 21-4-3-4,
[21:56.000 --> 21:58.000]  that's a new security standard.
[21:58.000 --> 22:01.000]  It asks for similar things than the safety standards.
[22:01.000 --> 22:03.000]  Yeah, I do have a great system.
[22:03.000 --> 22:06.000]  Yeah, that's possible.
[22:06.000 --> 22:08.000]  I need a consistent set of documents,
[22:08.000 --> 22:10.000]  documenting that I have a great system.
[22:10.000 --> 22:13.000]  Eh, that's where we might have a problem.
[22:13.000 --> 22:16.000]  That are the things we're still looking into.
[22:16.000 --> 22:19.000]  And yeah, happy.
[22:19.000 --> 22:21.000]  If anybody wants to join us,
[22:21.000 --> 22:26.000]  we meet every Friday evening.
[22:26.000 --> 22:27.000]  We have a call.
[22:27.000 --> 22:29.000]  Every information you will find here
[22:29.000 --> 22:34.000]  at the page of the FUSA Special Interest Group
[22:34.000 --> 22:38.000]  at the SPDX project.
[22:38.000 --> 22:42.000]  Okay, so questions please.
[22:42.000 --> 22:44.000]  Feedback, comments.
[22:44.000 --> 22:46.000]  Do you think it's complete crap?
[22:46.000 --> 22:48.000]  Can this go somewhere?
[22:48.000 --> 22:49.000]  Yeah?
[22:49.000 --> 22:53.000]  So, you presented the process,
[22:53.000 --> 22:56.000]  like what it takes for safety case to be made.
[22:56.000 --> 22:57.000]  Yeah.
[22:57.000 --> 23:00.000]  But I could not get, like, what your group is doing.
[23:00.000 --> 23:03.000]  So are you building some tooling that enables you?
[23:03.000 --> 23:05.000]  Ah, okay, what the group is actually doing.
[23:05.000 --> 23:09.000]  How actually SPDX is being played here?
[23:09.000 --> 23:12.000]  Okay, so the question is,
[23:12.000 --> 23:14.000]  what is the group actually doing
[23:14.000 --> 23:16.000]  and how does SPDX come to play?
[23:16.000 --> 23:19.000]  So yeah, we do not define the process.
[23:19.000 --> 23:27.000]  So the process, the structures, just give me a sec.
[23:27.000 --> 23:30.000]  So the structure like this and how to do things
[23:30.000 --> 23:31.000]  is already there.
[23:31.000 --> 23:34.000]  How do I make these things?
[23:34.000 --> 23:38.000]  And there are a lot of ideas around how to connect these things
[23:38.000 --> 23:40.000]  to have the full traceability.
[23:40.000 --> 23:44.000]  It's from having handwritten tags in Word documents
[23:44.000 --> 23:48.000]  to using special life cycle tooling.
[23:48.000 --> 23:50.000]  These approaches are established,
[23:50.000 --> 23:56.000]  but they are not so well interconnected most of the times.
[23:56.000 --> 24:01.000]  And later when you come into frequent updates,
[24:01.000 --> 24:04.000]  product variations, then it's really getting hard
[24:04.000 --> 24:06.000]  to keep track of things.
[24:06.000 --> 24:11.000]  And the idea, what we are currently following
[24:11.000 --> 24:14.000]  is that each piece of this information
[24:14.000 --> 24:16.000]  doesn't need to be in a tool.
[24:16.000 --> 24:19.000]  It doesn't need to be in a special kind of format.
[24:19.000 --> 24:23.000]  We can connect these with these relationships from SPDX
[24:23.000 --> 24:30.000]  that are already in the 2.3 specification.
[24:31.000 --> 24:34.000]  We're doing the exercise of the mapping to check to make sure
[24:34.000 --> 24:37.000]  we're not missing anything for 3L as well.
[24:37.000 --> 24:40.000]  Yeah, so we, Kate just added,
[24:40.000 --> 24:45.000]  we do the exercise of the mapping that everything,
[24:45.000 --> 24:46.000]  sorry.
[24:46.000 --> 24:47.000]  We'll fit for the spec.
[24:47.000 --> 24:49.000]  Yeah, that we'll fit for the spec.
[24:49.000 --> 24:56.000]  And maybe things go into 3.0 or later.
[24:57.000 --> 25:01.000]  Yeah, is this a follow up or a next one?
[25:01.000 --> 25:04.000]  I just wanted to ask is there in Papamike
[25:04.000 --> 25:07.000]  an available example that we could check out?
[25:07.000 --> 25:12.000]  So the question is there a publicly available example?
[25:12.000 --> 25:13.000]  Not fully.
[25:13.000 --> 25:15.000]  So we're talking about how to create the use cases,
[25:15.000 --> 25:18.000]  how to create the overviews in the course.
[25:18.000 --> 25:25.000]  So you're always welcome to call in and see what we have.
[25:25.000 --> 25:27.000]  Right, I really like this.
[25:27.000 --> 25:30.000]  As an engineer, a solution architect,
[25:30.000 --> 25:33.000]  having something like that and all the traceability,
[25:33.000 --> 25:36.000]  particularly out to the external world of the regulations.
[25:36.000 --> 25:37.000]  So when we did the safety thing,
[25:37.000 --> 25:41.000]  we had 800, quite 800 documents to try and trace.
[25:41.000 --> 25:43.000]  And they're all changing.
[25:43.000 --> 25:46.000]  And actually you want to look at the impact assessment
[25:46.000 --> 25:50.000]  of that change, of change of regulation
[25:50.000 --> 25:51.000]  or move to a different market.
[25:51.000 --> 25:53.000]  You want to be able to see that.
[25:53.000 --> 25:55.000]  So if you could capture that,
[25:55.000 --> 25:58.000]  and whether it's cyber or safety or anything,
[25:58.000 --> 26:03.000]  having that traceability must be a great movement.
[26:03.000 --> 26:05.000]  So I'm sure people like Seaman would love it
[26:05.000 --> 26:07.000]  for this type of system thing, you know.
[26:07.000 --> 26:08.000]  Build the power station.
[26:08.000 --> 26:09.000]  Yeah.
[26:09.000 --> 26:11.000]  Yeah, this thing is, I don't know.
[26:11.000 --> 26:12.000]  I'm thinking of adding to shift.
[26:12.000 --> 26:15.000]  I'm basically already had huge amounts of things
[26:15.000 --> 26:19.000]  about safety and the main and international stuff like that.
[26:19.000 --> 26:22.000]  So capturing all this in a thing
[26:22.000 --> 26:24.000]  so you can see the relationships and change
[26:24.000 --> 26:26.000]  so you can see the local effect.
[26:26.000 --> 26:29.000]  If this went up from version one to version two,
[26:29.000 --> 26:31.000]  where's the impact?
[26:31.000 --> 26:32.000]  Which part of the design?
[26:32.000 --> 26:34.000]  Which part of the supply chain?
[26:34.000 --> 26:35.000]  Yeah, exactly.
[26:35.000 --> 26:37.000]  Yeah, I would also love to have this.
[26:37.000 --> 26:40.000]  At the moment, the idea is really,
[26:40.000 --> 26:42.000]  okay, I need the evidence for me
[26:42.000 --> 26:44.000]  because I need to be sure what I have
[26:44.000 --> 26:45.000]  and what I have deployed.
[26:45.000 --> 26:49.000]  But yeah, the next thing is I'm a component part
[26:49.000 --> 26:51.000]  or I'm making component part
[26:51.000 --> 26:55.000]  and I ship this down the supply chain.
[26:55.000 --> 26:57.000]  And the next one who wants to consume this
[26:57.000 --> 26:58.000]  wants the information.
[26:58.000 --> 27:01.000]  And it doesn't make, maybe not want,
[27:01.000 --> 27:05.000]  I don't want to give out all the information that I have,
[27:05.000 --> 27:07.000]  but I can give the relationships
[27:07.000 --> 27:08.000]  and the completeness information
[27:08.000 --> 27:10.000]  and I can do this in an automated way
[27:10.000 --> 27:14.000]  that can go into an automated supply chain process.
[27:14.000 --> 27:15.000]  You've passed the supply chain,
[27:15.000 --> 27:17.000]  you've passed the relevant bits of the standard.
[27:17.000 --> 27:18.000]  Exactly.
[27:19.000 --> 27:20.000]  Everyone follows this thing
[27:20.000 --> 27:23.000]  because actually 95% of those standards.
[27:23.000 --> 27:26.000]  Oh, time's up, time's up.
[27:26.000 --> 27:27.000]  Sorry.
[27:27.000 --> 27:30.000]  So yeah, it would be great to follow up on this.
[27:30.000 --> 27:32.000]  Please meet us on Fridays in the evening
[27:32.000 --> 27:33.000]  if you want to.
[27:33.000 --> 27:37.000]  And yeah, I'm happy to talk about this later
[27:37.000 --> 27:39.000]  with whoever shows up.
[27:39.000 --> 27:41.000]  Thank you very much.