OETCS/WP7/D7.1 – 00/05, Page 5, Section 2.1 (B)

[KlausRuedigerHase]

The following section:

"B. In contrast to the previous proposals, this one starts bottom-up, starting with the assumption that code generation from B models is possible and practical. This toolchain proposes working with B on the bottom two layers, but leaves open how these are connected to the Papyrus-based top. The biggest advantage of this approach is that the resulting model will be usable, and that there is a rich existing ecosystem for B, both open source and commercial. The biggest drawback is that there are many blanks to fill in, which may require significant development work."

should be rephrased as follows:

"B based Tools Chain: In contrast to the previous proposals, this one starts bottom-up, starting with the assumption that code generation from B models is possible and practical. This tools chain proposes working with B (e.g. Atelier B) on the bottom two layers, but leaves open how these are connected to the Papyrus based top. The biggest advantage of this approach is that it supports semi-formal as well as strictly formal modeling work and that there is ample of experience and the resulting models will be usable, and that there is a rich existing ecosystem for B, both open source and closed source. The biggest drawback is that there are many blanks to fill in, which may require significant development work, however by coordinating this approach with the POLARSYS industrial working group inside the eclipse ecosystem, those work can be shared with other stake holders in the tools development domain for safety critical model driven software design. Therefore this tools chain is not intended to be used in the first phase of the openETCS modeling project in WP3 however once it is operational it is planned to migrate results from the previous tools chain to the B based Tools Chain. By utilizing the POLARSYS activities as much as possible, especially a migration path has to be defined from the closed source SCADE tools chain to the B based Tools Chain in order to accommodate SIL4 software development based on SIL4 modeling work for further SRS development in the future. Artifacts generated by the SCADE Tools Chain should be able to be imported or converted in a way that the B based Tools Chain is able to process them. It is subject to further evaluation if a Domain Specific Language (DSL) equal or similar to the one chosen in the EFL approach can be adapted in one of the top layers of the tools chain. The goal for developing this tools chain is to fully support the "open Proofs" idea, that is: Open Source & Formal Proof"

[jastram]

I wasn't aware that Polarsys is concerned with B - is it? Instead, I would have expected references to FP7 Advance or SafeCap.

Further, Section 2.1 is meant to provide just a brief overview of the three toolchains. Therefore, I would see this content in Appendix C, rather than 2.1. We can discuss this at the review telco.

[jastram]

Dear Klaus-Rüdiger and Alexander,

We discussed the following issue at today's review meeting, and together, you can probably resolve it:

https://github.com/openETCS/toolchain/issues/135

Thanks,

• Michael

[astante]

I would propose to soften:

"The biggest drawback is that there are many blanks to fill in, which may require significant development work ..."

• There are not more blanks to fill in than with other approaches. The only missing thing to have a fully usable toolchain is the missing link from SysML to B. All other components are available as reflected in Appendix C.
• I also wouldn't say that the transformation form SysML to B requires significant development work. If only the structure is transformed to B, the work can be completed quite soon.

"...however by coordinating this approach with the POLARSYS industrial working group inside the eclipse ecosystem, those work can be shared with other stake holders in the tools development domain for safety critical model driven software design."

• The work on the B toolchain is specific to openETCS, because we decided to use SysML for the upper levels. I think the toolchain has to be developed or improved within openETCS. How a coordination with POLARSYS could looke like is unclear to me.

"By utilizing the POLARSYS activities as much as possible, especially a migration path has to be defined from the closed source SCADE tools chain to the B based Tools Chain in order to accommodate SIL4 software development based on SIL4 modeling work for further SRS development in the future"

• How to utilize POLARSYS activities to define a migration path from SCADE to B is unclear to me.
• It also reads like a migration path from SCADE to B would not be in the scope of openETCS.

"Artifacts generated by the SCADE Tools Chain should be able to be imported or converted in a way that the B based Tools Chain is able to process them."

• Just a note, It would be very hard to convert SCADE models to B models.

"It is subject to further evaluation if a Domain Specific Language (DSL) equal or similar to the one chosen in the EFL approach can be adapted in one of the top layers of the tools chain."

• This reads like introducing a new language to the B toolchain. I think at least the used languages are fixed. If a DSL will be introduced, that would be a different toolchain. If it is about reusing the EFS formalization efforts, then it should be rephrased.

[jastram]

In the 9-Sep-2013 Review Meeting, the core issues have been addressed as part of Decision 10, albeit with different wording. d45645848ead87c021ccc5ffd1d01bb40a0cba94