Hazard Tracking System for System-of-Systems …issc2016.system-safety.org/P02_Zenga_HTS_SoS.pdfTONY...

T O N Y Z E N G A

C M T I G R O U P I N C .

A U G U S T 2 0 1 6

Hazard Tracking System for System-of-Systems

Tutorial

1

t z e n g a @ c m t i g r o u p . c o m

( 5 1 4 ) 8 2 5 - 7 8 4 5

© CMTIGroup Inc. Hazard Tracking System for System of Systems (August 2016)

http://www.cmtigroup.com/

Agenda

2

2

1 System Safety Engineering Improvement Opportunities

Terms & Definitions

Hazard Management

Drawback with current Hazard Analysis documentation methods (Top 10)

System Safety Engineering Program per DI-SAFT-81626

External Stakeholders

Mishap Grouping & Taxonomy

Hazard Analysis & Tracking System View:

PHL – PHA – SSHA – SHA - O&SHA – SoS - Safety Verification

SoS Consideration

SSHA, SHA & SoS Hazard Analysis Interface

2

4

3

5

7

8

6

9

10


System Safety Engineering Improvement Opportunities

Despite the progress made in the System Safety Engineering discipline we continue to see safety related issues such as:

Automobile Fatalities & high number of Safety Recalls Train Derailments / Runaway & Environmental Impact Aviation Incidents

System Safety Critical system development challenges facing the industry include:

System Complexity (Requirements, design hardware, software, testing and users operators and support staff)

Competitive marketplaces are demanding lower-cost customized products that will meet ever-changing needs: and they are wanted now.

Quick deployment time (from contract award to system revenue service) Number of geographically diverse subsystem suppliers involved in silo Outsourcing of System safety engineering activities & cultural gaps Timing of Safety Information sharing (subsystem supplier to integrator to end user)

3


Terms & Definitions

4

Terms Definition

Hazard Any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of a

system, equipment or property; or damage to the environment.

Mishap An unplanned event or series of events resulting in death, injury, occupational illness, or damage to or loss

of equipment or property, or damage to the environment.

Subsystem An element of a system that in itself may constitute a system.

System A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and

software. The elements of this composite entity are used together in the intended operational or support

environment to perform a given task or achieve a specific production, support, or mission requirement.

System-of-systems A set or arrangement of interdependent systems that are related or connected to provide a given capability.

The loss of any part of the system will degrade the performance or capabilities of the whole.

An example of an SOS could be interdependent information systems. While individual systems within the

SOS may be developed to satisfy the peculiar needs of a given user group, the information they share is so

important that the loss of a single system may deprive other systems of the data needed to achieve even

minimal capabilities.

Source: Department of the Army Pamphlet 385–16 Safety System Safety Management Guide



a. The system safety organization or function within the organization of the total program to show the organizational and functional relationships, and lines of communication.

b. The responsibility, authority, and accountability of system safety personnel, other contractor organizational elements involved in the system safety effort, subcontractors, and system safety groups. Identify the organizational unit responsible for executing each task. Identify the authority in regard to resolution of all identified hazards.

c. The staffing of the system safety organization for the duration of contract to include manpower loading and the qualifications of assigned key personnel.

5

2.1 SYSTEM SAFETY ORGANZATION

DESIRED OUTCOMEDRIVER

• Functional interfaces are established amongst all stakeholders including internal and external suppliers and customer(s).

• Interfacing boundaries are established to ensure system safety tasks are within scope and contractual responsibility.

• Decision maker to determine when mitigations are sufficiently mitigated

• Knowledgeable resources are assigned to the System safety program for the duration of the project.



6

The process through which contractor management decisions will be made to include notification of critical and catastrophic hazards, corrective action taken, mishaps or malfunctions, waivers to safety requirements, and program deviations.

2.1 SYSTEM SAFETY ORGANZATION

DESIRED OUTCOMEDRIVER

• A person must be appointed with responsibility for tracking and management of hazards.

• With ability to define hazards with little or no ambiguity; so that hazards can be effectively mitigated, dispositioned and worded in such manner to maintain the safety case integrity.



a. Identify safety milestones so that evaluations of the effectiveness of the system safety effort can be made at Quarterly Program Reviews.

b. Provide a program schedule of safety tasks showing start and completion dates, reports, reviews, and man loading, in relationship to other program milestones.

c. Identify integrated system activities (i.e., design analyses, tests, and demonstrations) applicable to the system safety program but specified in other engineering studies to preclude duplication. Included as a part of this section shall be the estimated manpower loading required to do these activities.

7

2.2 System Safety Program Milestones

DRIVERDESIRED OUTCOME

• Metrics derived from the Hazard Tracking System (HTS), used to show the progress of the safety program (e.g., # of hazards, mitigation acceptance, verification status …)

• Safety task decomposition, assigned loading resources, start and end dates. Program Milestones linked to the HTS, etc.

• E.g., Systems engineering– safety related trade-off studies , performance analysis, testing etc., as attachments to support safety analysis.



a. Describe or reference the methods that will be used to identify and apply safety/hazard control. List the safety standards and system specifications that are the sources of safety requirements with which the contractor is required to comply and any others he/she intends to use.

b. Describe the risk assessment procedures. The hazard severity categories, hazard probability levels, and the system safety precedence to be followed in satisfying safety requirements shall be in accordance with MIL-STD-882.

c. Describe the integration of subcontractor equipment safety information.

8

2.3 SYSTEM SAFETY REQUIREMENTS

DRIVER

• Hazard analysis process and program system specification used for safety mitigating requirements are closely coupling. The HTS facilitates linkage between specification and hazard mitigation.

• HTS standardizes the Risk assessment process, program definitions, hazard categories and Risk threshold. Including identification of system safety precedence for each mitigation.

• Hazard integration process is facilitated with use of cross organization HTS.

• Subsystem Hazard alignment is based on Mishap categories.

DESIRED OUTCOME



a. The analysis technique and format that will be used in qualitative and quantitative analysis to identify hazards, their causes and effects, and recommended corrective action.

b. The depth within the system to which each analysis technique will be used including hazard identification associated with the system, subsystem, components, personnel, ground support equipment, government furnished equipment, facilities, and their interrelationship in the logistics support, training, maintenance, transportability, and operational environments.

c. The technique for establishing a single closed-loop hazard tracking system.

9

2.4 Hazard Analysis

DRIVER DESIRED OUTCOME

a. HTS provides a standard format for qualitative and quantitative analysis and decomposes hazards, their causes and effects, and recommended corrective action in terms of specification or derived requirements to be added to the subsystem / system specification for implementation and verification.

b. The HTS contains PHL, PHA, SSHA, SHA, …SoS hazard analysis results within same environment.

c. Results in a single closed-loop hazard tracking system.



The verification requirements for ensuring that safety is adequately demonstrated by analysis.

10


• Each analysis task type (SSHA, SHA, O&SHA, etc.) contains certifiable elements to ensure the safety program objectives are met for design and procedural mitigations.

• O&SHA mitigations are derived from mishaps, traced within the HTS.

• Procedural mitigations added to Operation and Maintenance manuals, used as training materials for personnel.

2.5 SAFETY VERIFICATION

DRIVER

Describe techniques and procedures to be used by the contractor to ensure that the objectives and requirements of the system safety program are met in the safety training for engineers, technicians, operating and maintenance personnel.

2.6 TRAINING

HTS Provides traceability between hazards cause, mitigating requirements and verification results of explicit or derived safety requirements.

DESIRED OUTCOME



Describe the mishap and hazardous malfunction analysis process for mishaps prior to delivery of the system.

11


An effective Hazard Tracking System:

a. During system development lifecycle, Mishaps are driving elements of the System Safety in the form of a Safety Taxonomy methodology.

When systems transition to revenue service – follow-up is required to ensure hazard control and safety devices are maintained via System Management System (SMS).

b. Applicable disciplines form part of the system and safety Interface / activities in the form of derived safety requirements or verification stakeholders.

2.7 MISHAP REPORTING AND INVESTIGATION

2.7.1 SYSTEM SAFETY INTERFACES

Identify the interface between system and safety and all other applicable disciplines, such as Maintainability, Quality Assurance, Reliability, Human Factors Engineering, Transportability Engineering, and Medical Support (Health Hazard Assessments).

DRIVER


12

Drawback with current Hazard Analysis documentation methods (Top 10)

Problem Statement Hazard Tracking System Benefits

1 Timeliness and End Customer review of risk mitigations:By the time the safety material is submitted to the customerit is too late to make design changes.

An effective Hazard Tracking system allows the End User /Customer to be a part of the system safety process from the start ofthe project till the end.

2 Inadequate subsystem supplier hazard analysis leavesthe System Integrators performing subsystem level hazardanalysis.

Subsystem suppliers contribute to the development of the safetycase. With direct access (through online comments) to thesubsystem supplier safety analysis; System Integrators can scrutinizesafety inputs in real time.It will simplify and expedite the system safety certification process.

3 End customer System acceptance and revenueoperations delay (including risks transferred to theCustomer).

When subsystem suppliers, integrators and customers work togetherthe result is an effective system safety program, with an increasedlevel of safety within cost and schedule.

4 Information filtered between customer integrator andsupplier.

A centralized Hazard Tracking System allows stakeholders toexchange comments, reviews and risk mitigation approvals.

5 Important safety program decisions and related riskmitigations details are lost, go missing or are entirelyomitted.

The Hazard Tracking System allows information to be tracked andlinked to pertinent hazards/mitigations to retain decision history.Useful against litigation.


13

Drawback with current Hazard Analysis documentation methods (Top Ten)


6 System Configuration Management of the program designbaseline.

The Hazard Tracking System will help track design baselinerevisions including, ECRs, ECO.

7 Justifying safety mitigations, instead of specifying thesystem mitigations through technical requirements.

Interface to Requirements Management process - Hazardmitigations requirements drive the system design and expeditessafety verification and product certification.

8 Inter/Intra-company processes and cross functional teamCommunication failure.

Simplification of safety design details exchange.

Improving safety through real time collaboration.Safety-critical subsystem / systems may be part of larger Systems-of-Systems involving development teams, from several organizations orcompanies, where hazard mitigations are most cost effectivelyapplied at various levels of the system.

Open exchange integrates safety mitigations from a variety ofsuppliers, resulting in linked safety data architecture.


14

Drawback with current Hazard Analysis documentation methods (Top Ten)


9 Building a captivating system safety culturewithin the project.

The goal of the Hazard Tracking System is to create and foster a System safety cultureto build, integrate, manage and Operate safety critical systems.

The Hazard Tracking System will facilitate links between procedures/processes,people, technology, regulations / guidance, facilities, materials, tools, equipment andperformance management.

The Safety Culture is part of an ongoing endeavor to address system development ofvarious stakeholders, in the safety critical industry.

10 Safety analysis and hazard mitigation aretypically scattered amongst several documents.

Traceability between SoS through Subsystemarchitecture, analysis, safety design andprocedural mitigation may be difficult to showwith current documentation reporting processes.

An effective Hazard Tracking system Integrates detailed safety analysis as:

a. Mishap – Hazard Mitigation traceability from SoS through SSHA

b. Failure Modes and Effect Analysis / Criticality Analysis (FMEA /

FMECA)

c. Subsystem or Integration Level Fault Tree Analysis (FTAs)

d. Technical requirements management tools.

e. Hazard Mitigation Verification Automated tools and results.



15

Hazard Management

Mishap Grouping & Taxonomy

16


External Stakeholders17


SSHA, SHA & SoSHazard Analysis Interface

18


SoS Consideration

Systems need to be adequately defined.

In the SoSenvironment if the train is defined as a System, a condition that causes it to stop less than a Safety defined distance (by braking curves) could be catastrophic

If the System is the Train and the propulsion stops then the hazard may not be catastrophic.

19


SoS Level of Complexity20

Source: Naval “Systems of Systems” Systems Engineering Guidebook Version 2.06 November 2006


Preliminary Hazard List (PHL)21


22

Preliminary Hazard Analysis (PHA)


23

Subsystem Hazard Analysis (SSHA)


System Hazard Analysis (SHA)24


25

System Hazard Analysis (SHA)


Operating & Support Hazard Analysis (O&SHA)

26


System of Systems Hazard Analysis (SoS)27


System of Systems Hazard Analysis (SoS)28


Safety Verification 29


Questions / Comments ? 30

Thank You for your attendance and participation.


Hazard Tracking System for System-of-Systems …issc2016.system-safety.org/P02_Zenga_HTS_SoS.pdfTONY...

Documents

Transcript of Hazard Tracking System for System-of-Systems …issc2016.system-safety.org/P02_Zenga_HTS_SoS.pdfTONY...