Engineering Service for Safety Analysis
FMEA (Failure Mode and effects analysis)
Concept
FMEA is a method used to evaluate risks of Failure Modes which can be found in the functions/design/processes of the system/hardware/software. It is a technique for safety analysis also used to analyze causes and impacts of failure modes to define measures for lessening or even averting the occurrence of failure modes. It is an inductive reasoning, which is performed in a ‘bottom-up’ manner. Both qualitative analysis and quantitative analysis are possible, but mostly, qualitative analysis is performed.
Service List
- System FMEA
- Hardware FMEA
- Software FMEA
- Process FMEA
Application Domain
- Automotive
- Automation
- Military
- Train
- Avionics
- Medical
- Mobile
- Shipbuilding
Related Diagram
FTA (Fault Tree Analysis)
Concept
FTA is an analysis technique used for both quantitative and qualitative analyses. It can be used to quantitatively assess the probability of eliminating failures or hazards, and to analyze complex effects caused by multiple-point failures. With FTA, the causes of failures are analyzed with tree structures. The top failure (hazard) that can be perceived by the driver is defined as the top undesired event (UE), and the causes are analyzed until the root cause is derived. Furthermore, with all the probabilities of analyzed causes, the probability of the top undesired event can be calculated. The goal of this analysis technique is to reduce the probability of failures by adding solutions for each root cause.
Service List
- System FTA
- Hardware FTA (qualitative + quantitative)
- Software FTA
- Process FTA
Application Domain
- Automotive
- Automation
- Military
- Train
- Avionics
- Medical
- Mobile
- Shipbuilding
Related Diagram
DFA (Dependent Failure Analysis)
Concept
When certain failures in a component are related to other failures, they are called dependent failures (in contrast to independent ones). Dependent failures may occur when one component is in a causal relationship with other components, or when an identical component is shared by multiple functions.
Types of Dependent Failures
- Common Cause Failure (CCF)
When a single event or root cause causes two or more elements in an item to fail, these failures are called common cause failures. CCFs are inevitable when a function is designed dual-structured or multi-structured. For example, when the same resources or values are used as input by various elements, all the related functions would fail if the values are faulty. Thus, CCF is a type of dependent failures and is differentiated from cascading failures.
- Common Mode Failure (CMF)
A common mode failure is a type of common cause failures (CCF) and it causes multiple components or parts to fail simultaneously. For example, as shown below, when the same software is used in a dual-structured design, the functions would fail regardless of input if the software malfunctions.
- Cascading Failures (CF)
A cascading failure is a failure in an element of a system, which is caused by a failure of other elements in the same item. In other words, cascading failures are a set of failures where a failure in one part/component can cause subsequent failures in other parts/components. For example, in a schematic diagram for power distribution, when a load is delivered through various paths, if a part fails causing a failure in one of the paths, it may subsequently lead to failures in the rest of the paths and components. A cascading failure is a type of dependent failures and shall be differentiated from a common cause failure(CCF)
Service List
- System DFA
- Hardware DFA
- Software DFA
Application Domain
- Automotive
- Automation
- Military
- Train
- Avionics
- Medical
- Mobile
- Shipbuilding
Related Diagram
FMEDA (Failure Mode Effect & Diagnosis Analysis)
Concept
In order to eliminate the probability of safety goal violation, hardware architectural metrics (HAM) and probabilistic evaluation of random hardware failures (PMHF) are calculated and evaluated to see if they satisfy the target values for the target safety level (ex. ASIL). HAM and PMHF are calculated with consideration for single-point faults, residual faults and latent faults based on failure rates of each hardware element.
Service List
- Hardware Architectural Metrics (Single Point Fault Metric, Latent Fault Metric)
- PMHF (Probabilistic Metric for random Hardware Failures)
- FMECA (Failure Modes, Effects & Criticality Analysis)
- Various System & Hardware Reliability Analysis
- Hardware component failure rate(FIT) Calculation according to IEC TR 62380, SN29500, Telcordia TR/SR, MIL-217, NSWC, GJB/z, FIDES
- Safety Mechanism Diagnostic Coverage Calculation
Application Domain
- Automotive
- Automation
- Military
- Train
- Avionics
- Medical
- Mobile
- Shipbuilding
Related Diagram
Semiconductor Safety Analysis
Concept
A safety analysis activity to check if semiconductor-level safety requirements are satisfied.(ISO PAS 19451 and ISO 26262 2nd edition part 11 applied)
-
Semiconductor FMEA
- Inside-semiconductor structure analysis
- Inside-semiconductor block function definition
- Inside-semiconductor block error definition
- Inside-semiconductor Safety Mechanism definition
- Semiconductor FMEA calculation
- Semiconductor safety requirement derivation
-
Semiconductor FMEDA
- Mission profile setting
- Calculation of base failure rate and effective failure rate for each part of semiconductor
- Failure rate calculation for semiconductor sub-parts
- Single Point Fault, Residual Fault, Latent Fault analysis for each failure mode
- Safety Mechanism Analysis
- Results (SPFM, LFM, PMHF, etc.)
-
Semiconductor FTA
- Inside-semiconductor failure analysis
- Qualitative FTA analysis
- Minimal cut set
- Quantitative FTA analysis
- Failure Frequency (ω), C.F.I (𝛌) calculation
-
Semiconductor DFA
- Inside-semiconductor independency check
- Redundant element analysis
- Dependent failures initiators analysis
- Measure for fault avoidance or control analysis
- Verification method analysisc
Service List
- Semiconductor FMEA
- Semiconductor FMEDA
- Semiconductor FTA
- Semiconductor DFA
Application Domain
- Digital components
- Analog components
- Intellectual Property
- Mixed signal components
- Programmable logic devices
- Microcontroller
- Multi-core components
- Sensors
- Transducers
Related Diagram
Software Product Line Engineering
About SPLE(Software Product Line Engineering)
SPLE is the development paradigm considering with technologies of reuse, business profits and technical strategies.
It is the technology getting attention in inside and outside of Korea to resolve the problems of reducing SW development time and ensuring quality competitiveness at the same time.
SW product line means the set of SW intensive systems to share common features and these systems are developed with common core asset which satisfies the specific requirements of the target market.
SPLE provides methodologies, technologies and supporting environments to make a related series of products with making the common core asset and using it to products production.
When you refer to the hall of fame of SW product line materials which are managed by SPLC, they have announced the hall of fame focusing on automobile, aviation and military domain. (☞ Hall of Fame – SPLC.net, http://splc.net/fame.html) Especially they officially adopt product line technology on AUTOSAR which is the development model of automobile domain or EAST-ADL which is the development language. (☞ EAST-ADL Association, http://www.east-adl.info)
SPLE Service
Unlike the general SW development, SPLE is divided into domain engineering to develop asset and application engineering to compose developed asset to products.
SPID provides various engineering service based on FORM(Feature-Oriented Reuse Method)[4] for domain engineering that analyze SW domain and develop asset and producing products efficient and effective.
- Domain Analysis and modeling
- Analysis product line requirements and detail methods
- Design methods of product line architecture
- Design methods of product line components/modules
- Application of product line implementation technology
Related Standard & Resources
- Feature Model (de facto standard)
- ISO/IEC 26550 Software and System Engineering – Reference model for product line engineering and management
- ISO/IEC 26551 ~ ISO/IEC 26556
- 지원 도구 : ☞ VULCAN Workbench
Analysis and Design
We provide analysis, design, implementation, test performance consulting to deliver the high quality of products on time based on SW Engineering principle. Also we provide SW developing process which are standardized and optimized to improve SW Engineering capability of organization.
Main issues by SW development
We optimize developing process from requirements definition to analysis/design, implementation and test according to organization characteristics and provide infra supporting efficient SW development implementation such as technologies, methods, etc.
SW Test
SPID supply software test consulting services based on V model (Verification and Validation) and depending of customer needs, test outsourcing service is also provided.
