[#422] adding SysML2B transformation and various correction.

T7.3/D7.3/D7.4.bib

@@ -325,7 +325,19 @@ @book{standard_railway_2011
 }
 
 
-
+@techreport{baro_d2.6_2013,
+	title = {D2.6 Requirements for {openETCS}},
+	rights = {{CC}-by-{SA}},
+	pages = {1--23},
+	number = {D2.6},
+	institution = {{openETCS}},
+	type = {Requirements},
+	author = {Baro, Sylvain and Welte, Jan},
+	date = {2013-04},
+	year = {2013},
+	note = {Cited by 0000},
+	keywords = {{OpenETCS}}
+}
 @techreport{pokam_report_2013,
 	type = {Requirements},
 	title = {Report on {CENELEC} standards},

T7.3/D7.3/example.tex

@@ -2,7 +2,8 @@
 \section{Bitwalker Model-Based Qualification Example}
 \label{sec:bitwalker-example}
 
-This section gives an example of a tool analysis model as described in Section~\ref{sec:model-based-tool-quali} based on the specification import function of the Bitwalker tool.
+This section gives an example of a tool analysis model as described in Section~\ref{sec:model-based-tool-quali} based on the specification import function of the Bitwalker tool. The example is by no means complete; its goal is to illustrate the concepts described in this document.
+
 \paragraph{Functions}
 
 \begin{tabular}{|lp{0.7\textwidth}|}
@@ -133,12 +134,21 @@ \section{Bitwalker Model-Based Qualification Example}
 
 \begin{tabular}{|lp{0.7\textwidth}|}
 \hline
-\multicolumn{2}{|c|}{\bf Correctness Inspection}\\
+\multicolumn{2}{|c|}{\bf VnVActivity1}\\
+\bf Type&Correctnes Inspection\\
 \bf Requirement&UC1/Success Condition\\
 \bf Description&Manually inspect whether all definitions of ArtifactSubset026-7 and ArtifactSubset026-8 are actually represented correctly in the Data Dictionary\\
 \hline
 \end{tabular}
 
+\begin{tabular}{|lp{0.7\textwidth}|}
+\hline
+\multicolumn{2}{|c|}{\bf VnVResult1}\\
+\bf V\&V Activity&VnVActivity1\\
+\bf Result&Passed/Failed\\
+\bf Findings&Descriptions of the findings of the inspection.\\
+\hline
+\end{tabular}
 
 
 \textbf{Remark: } It will be necessary to provide evidence that critical errors such as PotentialError2 or PotentialError4 can be detected or are not present in the tool. 

T7.3/D7.3/intro_soa.tex

@@ -13,11 +13,12 @@ \section{Tool Qualification}
 We recall here the different class definitions:
 \begin{itemize}
 \item Tool class T1: No generated output can be used directly or indirectly to the
-  executable code;
-\item Tool class T2: Verification tools, the tool may fail to detect errors or
+  safetey critical executable code;
+\item Tool class T2: Verification tools, e.g. that can not introduce
+  errors to the safety critical executable code but those tools may fail to detect errors or
   defects;
 \item Tool class T3: Generated output directly or indirectly  as part of the
-  executable code.
+  safety critical executable code.
 \end{itemize}
 The deliverable D2.2 \cite{pokam_report_2013} summarizes the requirements for the
 tool needed by the different tool classes. The report highlights that the
@@ -41,7 +42,16 @@ \section{Tool Qualification}
 regarding the fact that our development imply regular releases, a
 systematic toolchain analysis approach has to be defined.
 
-Table~\ref{tab:oetcs_tool_classification} exemplarily lists the tool classes for some of the tools employed in the openETCS project. The tools Papyrus, SCADE and Bitwalker have a direct effect on the generated code whereas ProR and Git do not. The classification for ProR would be different if it would be used for formal requirements that then could be automatically translated to a model (this would yield a T3-classification). The verification tools RTTester and CPN Tools are not in the ``direct'' chain from requirements to code but they may fail to detect errors in the software or model.
+Table~\ref{tab:oetcs_tool_classification} exemplarily lists the tool
+classes for some of the tools employed in the openETCS
+project. Automatic code generator for SCADE model such as KCG or the
+Bitwalker tool have a direct effect on the generated code whereas ProR
+and Git do not. The classification for ProR would be different if it
+would be used for formal requirements that then could be automatically
+translated to a model (this would yield a T3-classification). The
+verification tools RT-Tester and CPN Tools are not in the ``direct''
+chain from requirements to code but they may fail to detect errors in
+the software or model.
 
 \begin{table}[h]
 \begin{center}
@@ -135,7 +145,7 @@ \subsection{Asplund and al. (projects iFEST, MBAT)}
 
 In \cite{asplund_towards_2012}, they explore the step 2): identifying
 the required safety goals due to tool integration and obtaining a
-description of a reference work-flow and tool-chain with annotations regarding the mitigating effort.  They propos to use the TIL language, a
+description of a reference work-flow and tool-chain with annotations regarding the mitigating effort.  They propose to use the TIL language, a
 domain specific language for toolchain models.  The model of the tool
 chain is used to perform a risk analysis and to annotate parts
 that need mitigating effort for the safety issues due to tool

T7.3/D7.3/oetcs_qualification_process.tex

@@ -2,6 +2,8 @@
 % Use the option "nocc" if the document is not licensed under Creative Commons
 %\documentclass[nocc]{template/openetcs_article}
 \usepackage{todonotes}
+\usepackage{footnote}
+
 \usepackage{appendix}
 \usepackage{lipsum,url}
 \usepackage{pdfpages}
@@ -144,7 +146,7 @@ \chapter{Document Information}
 \hline
 \multicolumn{2}{|c|}{Review information} \\
 \hline
-Last version reviewed & 01.00 \\
+Last version reviewed & 01.11 \\
 \hline
 Main reviewers &  Marielle Petit-Doche, Michael JastramJ, Jaime Paniagua\\
 \hline
@@ -184,7 +186,10 @@ \chapter{Document Information}
 01.09 & 04.08.2014 & S. Rieger & Refined Chapter 2 \\
 01.10 & 08.08.2014 & C. Braunstein & Insert Izaskun De La Torre
 remarks\\
-01.11 & 12.08.2014 & S. Rieger & Took into account Izaskun De La Torre's remarks\\
+01.11 & 12.08.2014 & S. Rieger & Took into account Izaskun De La
+Torre's remarks\\
+01.12 & 02.10.2014 & C. Braunstein \& S.Rieger & Integrate WP2 review\\
+
 \hline  
 \end{tabular}
 \newpage

T7.3/D7.3/qualif_process.tex

@@ -27,6 +27,9 @@ \section{OpenETCS Tool Chain Characteristics}
 
 These goals will be included in our tool integration
 qualification, they will be extra requirements for each tool qualification.
+Moreover, a set of specific requirements has been described in the
+deliverable D2.6 \cite{baro_d2.6_2013}. These should also been
+included in the tool's requirements.
 
 In the following sections we define the tool chain qualification
 process by first giving an overview of the process (section
@@ -110,7 +113,7 @@ \section{Qualification Process Overview}
 installed. It does not verify that the tool chain conforms to the functional and performance specification. This is done later in the operational qualification phase. The goal of this step is to verify correct software installation and to document all computer hardware, software and configuration settings as the initial baseline configuration.
 
 \paragraph{Operational qualification}
-Operation qualification should demonstrate that the tool chain will function according to its operational specification in the selected environment. The tests should be performed to verify that the toolchain meets the specifications, requirements in the specific environment.
+Operational qualification should demonstrate that the tool chain will function according to its operational specification in the selected environment. The tests should be performed to verify that the toolchain meets the specifications, requirements in the specific environment.
 
 \paragraph{Performance qualification}
 Performance qualification should demonstrate that the toolchain consistently performs according to the specifications defined by the openETCS project, and is appropriate for the intended use. Important for consistent openETCS toolchain performance is regular preventive maintenance, making changes to the toolchain in a controlled manner and regular testing.
@@ -275,7 +278,7 @@ \subsection{Model-based Tool Qualification}
 \label{fig:qualification-models-linkage}
 \end{figure}
 
-The SysML block diagrams depicted in Figure~\ref{fig:tool_analysis_model} depicts the proposed qualification meta-model for openETCS. It needs to be instantiated for each individual tool. The tool analysis model is used to analyse the functions of the tool and potential errors and mitigations. Ideally, it shall establish the traceability between requirements, use cases, implementations and test cases.
+The SysML block diagrams depicted in Figure~\ref{fig:tool_analysis_model} depicts the proposed qualification meta-model for openETCS. It needs to be instantiated for each individual tool. The tool analysis model is used to analyse the functions of the tool and potential errors and mitigations which are the result of a thorough risk analysis. Ideally, the qualification meta-model shall establish the traceability between requirements, use cases, implementations and test cases.
 
 
 \begin{figure}
@@ -289,6 +292,10 @@ \subsection{Model-based Tool Qualification}
 meta-model. This can be seen as our template for collecting all
 information needed for tool qualification.
 
+For T3 tools it needs to be ensured that the set of potential errors that may lead to a safety problem is exhaustive. To this end, evidence must be provided. For T2 and T3 tools it is also necessary to provide evidence that the user manual is sufficiently detailed and free of errors that may lead to maloperation. 
+
+
+
 
 
 \section{Incremental Tasks for toolchain qualification}
@@ -305,7 +312,7 @@ \section{Incremental Tasks for toolchain qualification}
 \begin{enumerate} 
 \item Add a new tool: the tool chain is extended
 \item Replace a tool: a tool function is replaced by another one
-\item Update a tool: a tool is update (bug fixes, performance
+\item Update a tool: a tool is updated (bug fixes, performance
   improvements ...)
 \end{enumerate}
 
@@ -387,16 +394,18 @@ \section{OpenETCS Toolchain Qualification Process}
 the list of tools present in the tool chain as well as some
 information about them such as :  the name,  the version,
 a description and a list of dependency.
+These information should be included in the release documentation of
+the opentECTS tool chain.
 
 The list of tool should be refined by the development team.
 The missing information should be added directly in the
 sources to make them available for the next tool releases.
 
 
 From the work-flow of the tool chain it is possible to automatically
-derived some basic use cases such as parsing or producing
+derive some basic use cases such as parsing or producing
 artifacts. These basic use cases may be coupled with basic potential
-errors such as ``no file found'', ``too many file produced''...
+errors such as ``no file found'', ``too many files produced''...
 
 After the tool chain analysis phase, the {\bf individual tool qualification}
 starts. With the help of the tool list, the previous information given
@@ -405,30 +414,38 @@ \section{OpenETCS Toolchain Qualification Process}
 \ref{tbl:functions} summarise the set of information needed for the
 qualification of a tool.
 
+
+
 \begin{table}[htbp]
 \centering
 \caption{\label{tbl:tool-info}Tool Information to be completed}
+
 \begin{tabular}{|l|p{5cm}|}\hline
 Tool Name: & \\\hline
 Version: & \\\hline
 Tool License: & \\\hline
 Tool Origin: &\\\hline
 Tool Dependencies & \\
- & -\\
+(with version) & -\\
  & -\\ \hline
 Description: & \\
  & \\ \hline
 Tool Class: & \\\hline
 \multicolumn{2}{|c|}{If T2/T3 Tools}\\\hline
 Tool Justification & \\
  & \\ \hline
-Manual Link and version & \\\hline
+Manual or Specification & \\
+Link and version & \\\hline
 Artifact List link & \\\hline
 Function List link& \\\hline
 \multicolumn{2}{|c|}{If T3 Tools}\\\hline
-Validation method& \\\hline
+Evidence of correctness or  & \\
+failure detection \footnotemark& \\\hline
 VnV activities report link&\\\hline
 \end{tabular}
+
+\vspace{1em}
+$^1$\footnotesize{See EN50128 6.7.4.4 for the list of alternatives}
 \end{table}
 
 
@@ -463,16 +480,26 @@ \section{OpenETCS Toolchain Qualification Process}
 
 
 
-When all tool are completely defined the {\bf tool-to platform
-  integration} starts. From the previous phase, we should generate the
-dependency list of the tools and the artifact matrix.  The dependency
-list is used to check if all tool can be correctly integrated into the
-tool platform by the qualification team and report to the development
-team.  The artifacts allow the qualification team to check if all
-artifacts are correctly read and write and/or all possible errors are
-mitigated.  In case of re-qualification of the tool chain, the work
-may be alleviate by using  the artifacts matrix
-to concentrate on the tools that are impacted by the changes.
+When all tool are completely defined the {\bf tool-to-platform
+  integration} starts. From the previous phases, we should be able to generate
+the dependency list of the tools and the artifact matrix. The
+dependency list is obtained by following the work-flow  and the
+eclipse dependency list definition that includes the version of the tools.
+The dependency list is used to check if
+all tool can be correctly integrated into the tool platform by the
+qualification team and report to the development team. Part of this
+task may be automatically done by the Eclipse tool platform. 
+
+The artifacts matrix is the list of all artifacts produce within the
+tool chain with the link of each tool that uses, writes or reads it. 
+As required by \tt{R-WP2/D2.6-02-076} the input/output formats has to
+be documented.
+The artifacts matrix  allows the qualification team to check if all artifacts are correctly
+read and write and/or all possible errors are mitigated.  In case of
+re-qualification of the tool chain, impact analysis of the change
+shall be perform form the artifacts matrix. Hence,  the work may be
+alleviate by focusing on the tools that are impacted by
+the changes. 
 
 
 %% \paragraph{Tool Integration Process for Qualification}
@@ -531,4 +558,4 @@ \section{OpenETCS Toolchain Qualification Process}
 
 
 
-%%  LocalWords:  openETCS
+%%  LocalWords:  openETCS opentECTS

T7.3/D7.3/toolchainsamplequalif.tex

@@ -1,7 +1,6 @@
 In this section we will illustrate the qualification process for the
 openETCS tool chain.
-As an example we will focus on the sample tool cahin depicted figure
-\ref{fig:sample}
+As an example we will focus on the sample tool chain depicted in Figure~\ref{fig:sample}.
 
 \begin{figure}[h]
 \includegraphics[width=\textwidth]{toolchainsample1}
@@ -139,7 +138,7 @@
 
 The artifact matrix for the tool chain matrix should look like
 table \ref{tbl:example-artifacts}.
-This table has beed pre-filled with the information available now,
+This table has been pre-filled with the information available now,
 this should also be completed during the qualification process.
 
 \begin{table}[htbp]