Kpit Technologies Limited · NSE:KPITTECH
Kpit Technologies — ikv++ technologies — CTI ISO 26262 Conference 2012
19 slides from Kpit Technologies's conference presentation, November 2012
Slide 1: Consistent Application of Safety Analysis Methods using SysML Architecture Models
Consistent Application of Safety Analysis Methods using SysML Architecture Models エッカート・ホルツ Dr. Eckhardt Holz, ikv++ technologies ag CTI ISO 26262 conference – 27.-29. November 2012 , Tokyo, Japan
Slide 2: ikv++ technologies ag overview: key facts
ikv++ technologies ag overview 22 key facts German shareholder company products and solutions for automotive safety team of experienced safety engineers and software architects based in Berlin, Germany ikvテクノロジーズジャパン株式会社 Nagoya, Japan 10+ years in the market 120+ customers worldwide AU
Slide 3: ikv++ technologies ag product lines
ikv++ technologies ag product lines 33 medini™ analyze the integrated solution for the analysis of functional safety and reliability aspects according to standards such as IEC 61508, ISO 26262 and SAE ARP 4754 medini™ unite the product for change and configuration management support for model-ba
Slide 4: Role of system design models
role of system design models 44 the system design models are a key artifact for the integration of engineering and safety activities many safety activities require (at least preliminary) architectural information safety requirements need to be realized by specific design choices that need to b
Slide 5: Hierarchies in automotive system development
hierarchies in automotive system development 55 SysML Functions, Item w. messages <<alloc>> Malfunctions OEM <<refined>> Subsystem Subsystem SysML Functions, Subsystem w/ signals, FM <<alloc>> Malfunctions Tier 1 <<refined>> SysML Part library w/ signals/electrics, <<uses>> (SysML) HW-FM, BOM Tier 1
Slide 6: (1) SysML model import into medini analyze
(1) SysML model import into medini analyze 66 1 Bumper Sensor:Crash sensor 1 Inflator P:Inflator Attributes outgoing:int Attributes incoming:int development of a SysML model with Operations Rhapsody Operations model is produced as result of the 1 ACU:Controler ordinary development process Attrib
Slide 7: (2) Establishing relations between model elements
(2) establishing relations between model elements 77 the imported model is traced to other model elements an example is the allocation of functional safety requirements imported preliminary architecture Functional Safety Requirements such semantic links are used to relate or compute safety inf
Slide 8: (3) Specification of safety properties
(3) specification of safety properties 88 extension of the architecture by safety properties failure modes and failure rates must be specified for the elements of the safety architecture such data can be calculated or taken from common catalogs such as SN 29500, IEC 62380 or Birolini Safety Hand
Slide 9: (3) Specification of safety properties
(3) specification of safety properties 99 Step-by-step guidance through the catalog to determine the failure rates for all elements
Slide 10: (3) Specification of safety properties
(3) specification of safety properties 10 10 parameter values which may influence the failure rate can be defined at elements level or for be derived from parent components
Slide 11: (3) Specification of safety properties
(3) specification of safety properties 11 11 Imported from BOM or ECL excel all entries with refers to entry in library the same part number have the same failure information Failure data derived from library Element Library
Slide 12: (4) Verification of the technical safety architecture
(4) verification of the technical safety architecture 12 12 the system architecture is analyzed concerning violations of the safety goal failure modes and rates of the architectural elements used as source for probability values Drag&Drop from architecture to FTA FTA trees are constructed and
Slide 13: (4) Verification of the technical safety architecture: required by ISO 26262 part 5
(4) verification of the technical safety architecture 13 13 required by ISO 26262 part 5: Evaluation of diagnostic coverage for Evaluation of diagnostic coverage of all Single Point Faults of components all Latent Faults, which have which have the potential to directly together with another faul
Slide 14: (4) Verification of the technical safety architecture
(4) verification of the technical safety architecture 14 14 shows if all FRC metrics (SPF/RF/LF) are fulfilled for element
Slide 15: (4) Verification of the technical safety architecture
(4) verification of the technical safety architecture 15 15
Slide 16: (5) Model update in case of design change
(5) model update in case of design change 16 16 1 Bumper Sensor:Crash sensor 1 Inflator P:Inflator Attributes outgoing:int Attributes incoming:int design changes may lead to a changed Operations Rhapsody model Operations safety analysis needs to be repeated 1 ACU:Controler new model can be re-
Slide 17: Consistency among design and safety analysis
Consistency among design and safety analysis 17 17 Fault Derive ISO 26262 Tree SPF & LF metrics Analysis diagnostic coverage SysML Models Update Update Derive Review/Assesment FMEA & FMEDA Checklists Review
Slide 18: Benefits
benefits 18 18 increased awareness of the engineering team for functional safety significant reduction of the work-effort for the safety analyses in round- trip engineering, easier comparison of different architecture variants, consistency and traceability among the different work products a
Slide 19: Software for safety
software for safety ikv++ technologies ag Dessauer Str. 28/29 D-10963 Berlin ikv technologies japan 株式会社 〒451-6040 愛知県名古屋市西区牛島町6番6号名古屋 ルーセントタワー40階 © ikv++ technologies ag 2012