Viser opslag med etiketten Verification and Validation. Vis alle opslag
Viser opslag med etiketten Verification and Validation. Vis alle opslag
mandag den 19. januar 2009
Results from former poll's
Poll 7
Can the Safety Management system be merged into the Quality Management system?
Result: 'Yes' (62%), 'No' (37%)
The Safety Management System "produces" the Safety plan that defines task, roles and procedures. Such input is well-placed in the Quality Management system in an Organization. From this point of view, the answer is a plain 'Yes'. However, it has some drawbacks concerning the Safety Approval work if the two systems are merged into one system without a possibility to distingiush between Safety and Quality tasks: Any change in any procedure in the Quality System must subsequently be presented to the Safety Authority because it potentially have an impact on Safety.
But the answer is 'Yes'.
Poll 6
Are bonus arrangements suitable for Operational staff as regularity increasing measure?
Result: 'Yes' (43%), 'No' (56%)
The question was raised by the Chinese delegation at an international railway safety conference. They concluded that when the staff was paid with bonus arrangements if regularity increased, then they had a tendency to jeopardize the safety. As an example, incidents had occurred where the train driver started the train when an umbrella was stuck in the door, forcing the passengers on platform to jump.
Therefore, the answer must be 'No'.
Poll 5
Is Independency intact, if the Project Manager and the Validator report to separate Managers, but have office jobs side by side?
Result: 'Yes' (65%), 'No' (35%)
There has to an adequate level of independency between the Project Manager and the Validator. This independency is intact because they report to different managers. From this point of view, I agree with the 'Yes' voters.
However, during a project lifetime a number of disagreements must be expected between the Project Manager and Validator e.g. whether a change-request should be validated by a time-costly retesting.
It is more comfortable for both parts to be located in different offices during such conflicts.
Therefore, I lean towards the 'No'.
Poll 4
Do simple and low-level safety-related projects have a bagatelle border for approvals?
Result: 'Yes' (38%), 'No' (62%)
It is a question often raised by e.g. operational staff: "We need to change this rubber pipe to another type, urgently - can we do it? It is such a small item without any safety relevance!"
If there was a bagatelle border, who should decide whether the change was below or above the border and on which basis? In order to take such a decision, it is necessary to make a fast risk analysis, define the safety function affected by the change etc. in the head - so why not write it down on some very simple key documents?
Therefore, I agree with the 62%.
Poll 3
Is an ISO 9001 certificate a basic EN 50126 requirement?
Result: 'Yes' (40%), 'No' (60%)
The voting result reflects the ambiguity in the EN 5012x suite; EN 50128 (about software) states that ISO 9003 is a basic requirement. But EN 50126, chapter 5.3.5.d) states there “shall be a quality management system compliant with the requirements of ISO 9001”, meaning ISO 9001 is not a formal requirement.
Poll 2
In which phase should the first revision of the 'Safety plan' be released?
Result: 'Concept' (46%), 'System Definition' (46%), 'Risk analysis' (7%), 'System requirements' (0%)
The voting result shows an agreement among the voters that it has to be in either the 'Concept' phase or in the 'System Definition' phase. According to Figure 9 in EN 50126, it has to be in the System Definition phase. See the Figure in chapter "Focus on the Source" in The Key Documents.
Poll 1:
Would you name the task "to inspect a train and report it ready for test runs" as:
Result: Verification (70%), Validation (10%), Assessment (20%)
I agree with the 70 % majority. I consider it as a verifying task, stating that we are ready to move on to the next phase in the V-model. See further explanation in chapter "Interpretation", question 1 in the quiz in verification, validation and assessment.
Read more...
onsdag den 5. november 2008
The key documents
A number of documents can be considered as "key" documents in a Safety Management system based on EN 50126.
The System definition: Defines the system on block diagram level.
The Safety Plan: Describes "Who does what and when".
The Hazard log: Contains all known hazards and their history.
The Risk analysis: Contains the risk analysis performed for each hazard.
The Safety Requirements: The safety requirements to the system
The Safety Case: The document that proves the system is safe.
Interpretation
An Operator, Infrastructure owner or Supplier organization might have thousands of small projects every year and maybe a few large projects.
It is some times asked: "Do who need all these documents for each single small project?".
The answer is "Yes" - however, it is allowed to simplify the documents to one A4 page.
Of course you need the documents! Imagine it was a small company saying: "We are so small that we do not need a yearly accounting report for the taxes authority".
If you do not have the key documents, everybody around you gets confused: The Safety authority, the safety department and the Assessor.
Next chapter >> 3.2 The System Definition
Focus on the source (EN 50126:1999)
In Figure 9 in EN50126, it is recommended to update the safety documents during the life cycle as shown below:
Information about the Safety organization and the FRACAS system can be included in the Safety Plan.
Infomation about relevant standards can be included in the Hazard log.
Information about the Risk acceptance criterion can be included in the Risk analysis.
Read more...
The System definition: Defines the system on block diagram level.
The Safety Plan: Describes "Who does what and when".
The Hazard log: Contains all known hazards and their history.
The Risk analysis: Contains the risk analysis performed for each hazard.
The Safety Requirements: The safety requirements to the system
The Safety Case: The document that proves the system is safe.
Interpretation
An Operator, Infrastructure owner or Supplier organization might have thousands of small projects every year and maybe a few large projects.
It is some times asked: "Do who need all these documents for each single small project?".
The answer is "Yes" - however, it is allowed to simplify the documents to one A4 page.
Of course you need the documents! Imagine it was a small company saying: "We are so small that we do not need a yearly accounting report for the taxes authority".
If you do not have the key documents, everybody around you gets confused: The Safety authority, the safety department and the Assessor.
Next chapter >> 3.2 The System Definition
Focus on the source (EN 50126:1999)
In Figure 9 in EN50126, it is recommended to update the safety documents during the life cycle as shown below:
Information about the Safety organization and the FRACAS system can be included in the Safety Plan.
Infomation about relevant standards can be included in the Hazard log.
Information about the Risk acceptance criterion can be included in the Risk analysis.
Read more...
tirsdag den 4. november 2008
Verification, Validation and Assessment
There is defined three different types of tasks and roles in EN 50126:
"Verification": The "Verificator" checks, if we are ready to move on to the next phase in the V-model.
"Validation": The "Validator" checks whether the physical systems behaves as it was supposed to do, i.e. horizontal tests and checks in the V-model.
"Assessment": The "Assessor" checks, if the processes in the Safety Management System are working as they should, i.e. the Safety Management Circle is turning. The assessor is not performing project tasks, the project would be made without the Assessor.
Figure 11, "Verification and Validation"
Interpretation
The difference between the different types of tasks and roles are not very clear between Verification and Validation.
But if Figure 11 is interpreted very strict, it is possible to identify the different types of tasks you meet in the daily Safety Management Life.
The table below shows some tasks that occur when a train is being prepared for take-over from a Supplier to an Operator:
The explanation to the table above is showed graphically below:
Verification example (no. 1): The task "Inspection check, to see if the train is ready for test driving" is a check, which verifies, that we are ready to move on from phase "Installation" in the V-model to the next phase "System Validation".
Validation example (no. 4): The task "Compile documentation showing fulfilment of safety requirements." is a task, which collects different types of proofs like test protocols and hereby validates that the installed system fulfils the requirements from the specifications.
Assessment example (no. 3): The task "Judgement, whether roles and responsibilities are defined in a safety plan, is a task which controls that a proper Safety plan actually exists for the project. It is not the task to actually write the Safety Plan.
Next chapter >> 2.4 Safety Approval process
Focus on the source (/EN 50126/)
The tasks are shown at Figure 11 (see above) and roles a described in the "Definitions" chapter of EN 50126:
Assessment: The undertaking of an investigation in order to arrive at a judgement, based on evidence, of the suitability of a product.
Validation: Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use have been fulfilled.
The objective of validation is to demonstrate that the system under consideration, at any step of its development and after its installation, meets its requirements in all respects.
Verification: Confirmation by examination and provision of objective evidence that the specified requirements have been fulfilled.
The objective of verification is to demonstrate that, for the specific inputs, the deliverables of each phase meet in all respects the requirements of that phase.
Read more...
"Verification": The "Verificator" checks, if we are ready to move on to the next phase in the V-model.
"Validation": The "Validator" checks whether the physical systems behaves as it was supposed to do, i.e. horizontal tests and checks in the V-model.
"Assessment": The "Assessor" checks, if the processes in the Safety Management System are working as they should, i.e. the Safety Management Circle is turning. The assessor is not performing project tasks, the project would be made without the Assessor.
Figure 11, "Verification and Validation"
Interpretation
The difference between the different types of tasks and roles are not very clear between Verification and Validation.
But if Figure 11 is interpreted very strict, it is possible to identify the different types of tasks you meet in the daily Safety Management Life.
The table below shows some tasks that occur when a train is being prepared for take-over from a Supplier to an Operator:
The explanation to the table above is showed graphically below:
Verification example (no. 1): The task "Inspection check, to see if the train is ready for test driving" is a check, which verifies, that we are ready to move on from phase "Installation" in the V-model to the next phase "System Validation".
Validation example (no. 4): The task "Compile documentation showing fulfilment of safety requirements." is a task, which collects different types of proofs like test protocols and hereby validates that the installed system fulfils the requirements from the specifications.
Assessment example (no. 3): The task "Judgement, whether roles and responsibilities are defined in a safety plan, is a task which controls that a proper Safety plan actually exists for the project. It is not the task to actually write the Safety Plan.
Next chapter >> 2.4 Safety Approval process
Focus on the source (/EN 50126/)
The tasks are shown at Figure 11 (see above) and roles a described in the "Definitions" chapter of EN 50126:
Assessment: The undertaking of an investigation in order to arrive at a judgement, based on evidence, of the suitability of a product.
Validation: Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use have been fulfilled.
The objective of validation is to demonstrate that the system under consideration, at any step of its development and after its installation, meets its requirements in all respects.
Verification: Confirmation by examination and provision of objective evidence that the specified requirements have been fulfilled.
The objective of verification is to demonstrate that, for the specific inputs, the deliverables of each phase meet in all respects the requirements of that phase.
Read more...
lørdag den 27. september 2008
The V-model
The EN50126 process is based on a general lifecycle view; the lifecycle starts when the product (e.g. an interlocking system, a train, an LED-lamp etc.) is in a concept phase. Then the product is developed, approved and put into operation and finally it is disposed. This lifecycle is expressed in the V-model, see Figure 10 from EN 50126 below.
Interpretation
Please note the V-model can be viewed as a time-line, which is bended down to form a "V". The product moves sequentially from phase 1, "Concept", to phase 2, "System definition and application conditions", etc.
The V-model is created (by the working group) in order to handle all Railway systems - simple as well as complex.
In the daily life, the fourteen phases of the V-model can be compiled and simplified into a model that smoothly fits into the product in question.
However, the main idea of viewing a product as going through life-cycle phases, on a V-shaped time-line, should be intact.
Example 1:
We would like to install entertainment video screens in a train fleet. For this product, it should be sufficient with three phases: "Design", "Installation" and "Operation". The V-model can then be compiled and simplified into the Figure below:
Example 2:
A more complex system, like e.g. a new supervisory system in a major city, controlling many sub stations, is planned to be set into service in steps: Mission 1 includes the first 10 sub station on a single line, Mission 2 includes all stations on the line etc.; until the Final mission, where all sub stations in the city are supervised.
For such a system, the V-model can be viewed as a life-cycle line, where you step back to a former appropriate phase each time a mission has reached phase "Operation" and the preparation for the next mission starts. For example, the project might step back to phase "Design and Implementation of mission 2" once the phase "Operation of mission 1" has been reached, See the Figure below:
Next chapter >> 2.3 Verification, Validation and Assessment
Focus on the Source (EN50126:1999)
The life-cycle concept is explained already in the scope of EN 50126, chapter 1.1:
"This European Standard: - defines a process, based on the system lifecycle and tasks within it, for managing RAMS;"
In chapter 5 is Figure 10 (from above) explained:
5.2.6
This standard represents the system lifecycle sequentially. This representation shows individual phases and the links between phases. Other lifecycle representations are widespread within industry and include the ”V” model.
5.2.7
A ”V” representation of the lifecycle contained within this standard is shown in figure 10. The top-down branch (left side) is generally called development and is a refining process ending with the manufacturing of system components. The bottom-up branch (right side) is related to the assembly, the installation, the receipt and then the operation of the whole system.
And finally is chapter 6, describing each phase in the V-model.
Read more...
Interpretation
Please note the V-model can be viewed as a time-line, which is bended down to form a "V". The product moves sequentially from phase 1, "Concept", to phase 2, "System definition and application conditions", etc.
The V-model is created (by the working group) in order to handle all Railway systems - simple as well as complex.
In the daily life, the fourteen phases of the V-model can be compiled and simplified into a model that smoothly fits into the product in question.
However, the main idea of viewing a product as going through life-cycle phases, on a V-shaped time-line, should be intact.
Example 1:
We would like to install entertainment video screens in a train fleet. For this product, it should be sufficient with three phases: "Design", "Installation" and "Operation". The V-model can then be compiled and simplified into the Figure below:
Example 2:
A more complex system, like e.g. a new supervisory system in a major city, controlling many sub stations, is planned to be set into service in steps: Mission 1 includes the first 10 sub station on a single line, Mission 2 includes all stations on the line etc.; until the Final mission, where all sub stations in the city are supervised.
For such a system, the V-model can be viewed as a life-cycle line, where you step back to a former appropriate phase each time a mission has reached phase "Operation" and the preparation for the next mission starts. For example, the project might step back to phase "Design and Implementation of mission 2" once the phase "Operation of mission 1" has been reached, See the Figure below:
Next chapter >> 2.3 Verification, Validation and Assessment
Focus on the Source (EN50126:1999)
The life-cycle concept is explained already in the scope of EN 50126, chapter 1.1:
"This European Standard: - defines a process, based on the system lifecycle and tasks within it, for managing RAMS;"
In chapter 5 is Figure 10 (from above) explained:
5.2.6
This standard represents the system lifecycle sequentially. This representation shows individual phases and the links between phases. Other lifecycle representations are widespread within industry and include the ”V” model.
5.2.7
A ”V” representation of the lifecycle contained within this standard is shown in figure 10. The top-down branch (left side) is generally called development and is a refining process ending with the manufacturing of system components. The bottom-up branch (right side) is related to the assembly, the installation, the receipt and then the operation of the whole system.
And finally is chapter 6, describing each phase in the V-model.
Read more...
Abonner på:
Opslag (Atom)
