-
Notifications
You must be signed in to change notification settings - Fork 22
Small How To in checking the SCADE Architecture of the EVC
This verification is - due to time constraints - only covering the direction Subset-026 --> SCADE model.
Current grooming issue https://github.com/openETCS/validation/issues/305
Inside the grooming issue the SCADE module to be verified is groomed. The SCADE module describes a set of packages and its sub-modules inside SCADE to be verified. The SCADE module is further described inside the ADD document, see setp 1.
The current ADD document is found in the modeling repository:
https://github.com/openETCS/modeling/tree/master/openETCS%20ArchitectureAndDesign/D3.5.3
The current document ist found via an ERA direct download link:
Inside the ADD Document the mapping of the module to the requirement ist found. The developer has entered the requirements claimed to be covered in the section Input Documents.
The current SCADE model is found in the modeling repository:
http://www.era.europa.eu/Document-Register/Documents/Index004%20-%20SUBSET-026.zip
The current document is found in the validation repository:
Fork the validation repository as described in https://github.com/openETCS/validation .
Copy the verification template to your folder inside your VnV user Story. Save the file to your local fork of the validation repository:
e.g. validation/tree/master/VnVUserStories/VnVUserStoryDLR/05-Work/ArchitectureVerification/name of module
Please rename the file to read: openETCS_architectureverification_ + name of module + .ods
Add the following columns (after column on-board) to the table:
- not relevant for EVC but for:
- allocated SCADE component
- allocated SysML architecture component (deriving from ReqCycle to SRS traceability *.csv export, Column:"AchrictectureVerification")
- SRS requirement
- findings in OETCS/WP3/D3.5.3 / Scade or result
- Classification
Mark the requirements (rows) that the developer claims to have covered by the model as described inside the ADD document by entering the name of module into the column allocated SCADE component. Only enter the name of module in columns having the column on-board marked with an x.
Looking at the SCADE model, evaluate the level of architecture as described in the SysML architecture model inside the ADD document and mapping the SysML components to the requirements inside ReqCycle.
Export the *.csv table with the SysML to Requirements traceability and add it to the excel table inside the column: SysML model element link to "AchrictectureVerification" coming from ReqCycle .
The link form the ADD document to the SCADE model follows the convention:
- Each folder mentioned inside Link to SCADE model contains only one *.etp file and several dependant *.xscade files. This *.etp file contains the described module.
- Each model component being described in a dedicated subchapter inside the ADD document is part of the architecture.
- Each model element being listed inside the description of the ADD document is part of the architecture.
Check marked requirements against ADD document and SCADE model and fill out the columns:
-
not relevant for EVC but for: - This column is a classification from the verifyer. If the requirement according to the current architecture is part of the OBU but not part of the EVC another entity to be expected to cover the requirement is entered here. This estimation needs to be acknowledged by the architecture. If this column is filled out, besides the acknowledgement from the architecture, no further step below is to be performed. The functionality is considered to be 'out of scope of the EVC'.
-
SRS requirement (optional) - a copy of the requirement from the SRS is an optional help for the verifyer. It represents a copy of the referenced requirement.
-
SCADE path to element - List all SCADE paths of referenced elements including the full package path. You can find the SCADE reference in Properties->General->Path
-
findings in OETCS/WP3/D3.5.3 / Scade or result
- if in any case the module is only covering part of the requirement, enter "the requirement is not fully covered by name of module"
- if an expected input is not available, enter "expected Input: name of input form SRS not handled by module: name of module"
- if an expected functionality is not available, enter "expected functionality: Name from the SRS nit handled by module: name of module".
- if an expected ouput is not available, enter "expected Output: name of output form SRS not handled by module: name of module"
- in case there are no findings and the requirement is fully covered on architecture level, enter "no findings"
- if the requirement is not covered at all, enter "the requirement is not covered"
- if the requirement is not completely covered in this module but completely or partially covered by another module, enter "the requirement SUBSET-026-number of requirement is not fully covered by name of module, see name of other package"
-
Classification - sums up the further steps
- If some input, output or functionality is missing, enter "grooming of module name is required"
- If some input, output or functionality is wrong, enter "correction of module name is required"
- If module completely or partially covered by another module enter "grooming of module name with other module name is required"
git add openETCS_architectureverification_ + name of module + .ods
git commit -m "Architecture Verification of _module name"
Ask review partner to review the work.
Via Github create pull request for your work adding the documents.
e.g. https://github.com/openETCS/validation/compare/master...MarcBehrens:master