Grooming of D4.3.3

[MarcBehrens]

Sections identified:

General structure: Subchapters included inside the main *.tex document allocated to single persons

• VnV on toolchain
  • SCADE (concerning safety and tool limitations): @janWelte @marcbehrens
  • Safety Architect @FrederiqueVallee
  • overview
  • tool qualification @jastram
• VnV on the process
  • overview
  • allocate the tools to the process steps used/ qualified
  • traceability: @janwelte @raphaelfaudou
  • detailed findings on the process
• Generic Safety Case performed on the model
  • overall look
  • work done on safety aspects
  • FTA @janWelte @AbdelnasirMohamed
  • safety architect: Error Propagation @francoisrevest @FrederiqueVallee
• Covering VnV documents Number 1-5 of document mapping

[janWelte]

Dear Collegues,

please see below the structure for D4.3.3. As I've indicated I strongly need your contributions to some parts.

For your contributions you are welcome to added the tex file for D4.3.3 or to create a seperate tex which can be included.

For every section I've added the person and some contentent point concerning the contributions I would exspect. If I forgot some work concerning the Process and toolchain verification and the safety case please let me know. I'm happy to receive every contribution.

Structure D4.3.3 needed contributions

Tool Chain

_overview_ @janwelte

_Tool Qualification_

@jastram (or other expert from WP7)

broad overview of the toolchain and the status of qualification (generall information can be placed in section Overview)

• which tools have to be qualified
• which tools are qualified? (in which way)
• how should qualification be address for tools with pending qualification

_SCADE_ @MarcBehrens @janWelte

• use of SCADE for quality assurance
• limitations of SCADE
• addressing safety issues and properties in SCADE (potential specific aspects in openETCS deviation from the usual use of SCADE)

_Safety Architect_ @FrederiqueVallee (or @FrancoisRevest)

• use of Safety Architect in openETCS (maybe addressing relation to Eclipse Safety Framework)
• function in development process
• inputs and outputs
• results (in general, and specific for openETCS)

OpenETCS Development

_overview_

@janWelte

Short overview of current work.

• Main principals to ensure consistency
• Mainly collecting findings
• allocate the tools to the process steps used/ qualified

_Compatibility to CENELEC standards_ @AbdelnasirMohamed

• overview results relation to EN 50126/50128 lifecycle
• reasons for deviations
• additional findings

_Traceability_

@raphaelfaudou (@janwelte)

• addressing specific position of traceability for safety argumentation
• introducing basic concept
• main findings (limitations)

Generic OpenETCS Safety Case

_System/ Sub-System Definition_ @janWelte and @BerndHekele

• general information concerning openETCs system and sub-system structure
• potential applications for artifacts

_Quality Management_ @AbdelnasirMohamed

• basic concept for quality management in openETCS
• missing aspects in quality management
• main finding to address additional measures to complete quality management

_Safety Management_ @janWelte

• basic concept for safety management in openETCS
• missing aspects in safety management
• main finding to address additional measures to complete safety management

_Functional/Technical Safety_ @janWelte

• addressing general system safety properties and allocation to functional structure
• listing needed integration properties for "safe" use of software model (specifically interface assumptions)

@FrancoisRevest

• addressing concrete findings from safety propagation analysis
• additional measures applicable to tackle open points

Conclusion -remarks are welcome by everyone

[jastram]

Here are my contributions regarding WP7. More information may be contributed by @idelatorre and @srieger .

broad overview of the toolchain and the status of qualification (generall information can be placed in section Overview)

We have a tool qualification process description: https://github.com/openETCS/toolchain/raw/a4f6ba766c3fb19914dba6f69c8952e557c7ffee/T7.3/D7.3/oetcs_qualification_process.pdf

However, as tool qualification is process specific and also expensive, no qualification has been done in the scope of the project. There was the hope that service providers would offer qualification to interested parties, and/or that corporations using the tooling in production would take care of the required qualification.

which tools have to be qualified

I thought all tools have to be qualified, if they are being used for production development?

which tools are qualified? (in which way)

We did not perform any tool qualification. However, I believe that Scade Suite/Systems is qualified, to a degree. Information needs to be retrieved from Systerel.

how should qualification be address for tools with pending qualification

N/A

[raphaelfaudou]

Jan,

Concerning traceability I suppose we can "pick" elements from "Traceability Architecture" document but I need some guidance about the 3 points you mentioned:

• addressing specific position of traceability for safety argumentation => I can explain that traceability is a powerful means to support verification of design artefacts wrt requirements but I can not make the link with safety (I’m not expert in safety argumentation). Any idea?
• introducing basic concept basic concept of traceability or of traceability as means to support safety argumentation?
• main findings (limitations) Which scope? architecture verification only or global traceability? should I focus on SCADE and SysML models only? or any other traceability links (for instance with MoRC safety case)?

Thanks

[janWelte]

Dear Raphael,

I would be thankful to have a short text from you in the deliverable, which just introduces the traceability in openETCS. Basically a short (one or two paragraphs) summary of your traceability architecture document.

I'll then add all the safety related aspects here, as good as it is possible in this project.

Do not at all consider the MoRC example, just the basic need of traceability and the existing OpenETCS ability.

Thanks a lot and sorry for the late answer.

Best regards

Jan

[raphaelfaudou]

Dear Jan,

here is attached my contribution on traceability (I’m not yet familiar with pull requests):

• .tex
• image You will find a little bit more than just two simple paragraphs but it should be easy for you to remove what is less important (perhaps the figure).

Best regards raphaël

Le 27 nov. 2015 à 09:45, Jan Welte notifications@github.com a écrit :

Dear Raphael,

I would be thankful to have a short text from you in the deliverable, which just introduces the traceability in openETCS. Basically a short (one or two paragraphs) summary of your traceability architecture document.

I'll then add all the safety related aspects here, as good as it is possible in this project.

Do not at all consider the MoRC example, just the basic need of traceability and the existing OpenETCS ability.

Thanks a lot and sorry for the late answer.

Best regards

Jan

— Reply to this email directly or view it on GitHub.

[janWelte]

Thank you very much Raphael,

That’s actually very helpful.

Thanks

Best regards,

Jan Welte

---

Dipl. Wirtsch.-Ing. Jan Welte

Research Associate

Institute for Traffic Safety and Automation Engineering Technische Universität Braunschweig

Tel.: +49 (0)531 391-66318 Fax: +49 (0)531 391-66399 j.Welte@tu-braunschweig.de

-----Ursprüngliche Nachricht----- Von: Faudou [mailto:notifications@github.com] Gesendet: Samstag, 28. November 2015 17:38 An: openETCS/validation validation@noreply.github.com Cc: Jan Welte j.Welte@tu-bs.de Betreff: Re: [validation] Grooming of D4.3.3 (#310)

Dear Jan,

here is attached my contribution on traceability (I’m not yet familiar with pull requests):

• .tex
• image You will find a little bit more than just two simple paragraphs but it should be easy for you to remove what is less important (perhaps the figure).

Best regards raphaël

Le 27 nov. 2015 à 09:45, Jan Welte notifications@github.com a écrit :

Dear Raphael,

I would be thankful to have a short text from you in the deliverable, which just introduces the traceability in openETCS. Basically a short (one or two paragraphs) summary of your traceability architecture document.

I'll then add all the safety related aspects here, as good as it is possible in this project.

Do not at all consider the MoRC example, just the basic need of traceability and the existing OpenETCS ability.

Thanks a lot and sorry for the late answer.

Best regards

Jan

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/validation/issues/310#issuecomment-160317442 . https://github.com/notifications/beacon/ACmA36jx22hCFmKeflTsSbe5vXXbmhroks5pKc_hgaJpZM4Gg5gh.gif