Topics covered

• Safety-critical systems
• Safety requirements
• Safety engineering processes

Safety

• Safety is a property of a system that reflects the system’s ability to operate, normally or abnormally, without danger of causing human injury or death and without damage to the system’s environment.
• It is important to consider software safety as most devices whose failure is critical now incorporate software-based control systems.

Safety

• Safety는 시스템이 정상적으로 또는 비정상적으로 작동하면서 인명 피해나 사망을 초래하지 않고 시스템 환경에 피해를 주지 않는 능력을 반영하는 시스템의 속성입니다.
• 대부분의 장치의 실패가 중요한 이유로 소프트웨어 기반 제어 시스템이 포함되어 있으므로 소프트웨어 안전성을 고려하는 것이 중요합니다.

Software in safety-critical systems

• The system may be software-controlled so that the decisions made by the software and subsequent actions are safety-critical.
  • Therefore, the software behaviour is directly related to the overall safety of the system.
• Software is extensively used for checking and monitoring other safetycritical components in a system.
  • For example, all aircraft engine components are monitored by software looking for early indications of component failure.
  • This software is safety-critical because, if it fails, other components may fail and cause an accident.
  • 2018~19 Boeing 737 MAX crashes.

Safety-critical systems에서의 소프트웨어

• 시스템은 소프트웨어 제어가 가능하므로 소프트웨어의 결정과 후속 조치가 안전에 중요합니다.
  • 따라서 소프트웨어의 동작은 시스템의 전체 안전성과 직접 관련이 있습니다.
• 소프트웨어는 시스템에서 다른 안전 중요한 구성 요소를 확인하고 모니터링하는 데 널리 사용됩니다.
  • 예를 들어, 모든 항공기 엔진 구성 요소는 구성 요소 결함의 조기 징후를 찾기 위해 소프트웨어로 모니터링됩니다.
  • 이 소프트웨어는 실패하면 다른 구성 요소가 실패하여 사고를 일으킬 수 있으므로 안전에 중요합니다.
  • 2018~19년 보잉 737 MAX 추락 사례가 있습니다.

Safety and reliability

• Safety and reliability are related but distinct.
  • In general, reliability and availability are necessary but not sufficient conditions for system safety.
  • Reliability is concerned with conformance to a given specification and delivery of service.
• Safety is concerned with ensuring system cannot cause damage irrespective of whether or not it conforms to its specification.
  • System reliability is essential for safety but is not enough.
  • Reliable systems can be unsafe

Safety와 reliability

• 안전성과 신뢰성은 관련되어 있지만 별개의 개념입니다.
  • 일반적으로 신뢰성과 가용성은 시스템 안전성에 대한 필요조건이지만 충분조건은 아닙니다.
  • 신뢰성은 주어진 사양을 준수하고 서비스를 제공하는 데 관심이 있습니다.
• 안전성은 시스템이 사양을 준수하든 아니든 피해를 입힐 수 없도록 보장하는 데 관심이 있습니다.
  • 시스템 신뢰성은 안전에 필수적이지만 충분하지 않습니다.
  • 신뢰할 수 있는 시스템이라도 안전하지 않을 수 있습니다.

Unsafe reliable systems

• There may be dormant faults in a system that are undetected for many years and only rarely arise.
• Specification errors.
  • If the system specification is incorrect, then the system can behave as specified but still cause an accident.
• Hardware failures generating spurious inputs.
  • Hard to anticipate in the specification.
• Context-sensitive commands
  • i.e.) issuing the right command at the wrong time.
  • Often the result of operator error

신뢰할 수 있지만 안전하지 않은 시스템

• 시스템에는 수 년 동안 감지되지 않은 동면 결함이 있을 수 있으며 이러한 결함은 드물게 발생합니다.
• 사양 오류.
  • 시스템 사양이 잘못되면 시스템이 사양에 따라 동작할 수 있지만 여전히 사고를 일으킬 수 있습니다.
• 하드웨어 결함으로 인한 잘못된 입력 생성.
  • 사양에서 예상하기 어려운 경우가 있습니다.
• 문맥에 따라 다른 명령
  • 즉, 잘못된 시간에 올바른 명령을 내리는 경우입니다.
  • 대개 작동자 오류의 결과입니다.

신뢰할 수 있는 시스템이지만 안전하지 않은 경우에는 여러 가지 원인이 있을 수 있습니다. 예를 들어, 시스템 내의 동면 결함이나 사양 오류, 하드웨어 결함으로 인한 잘못된 입력 생성, 문맥에 따라 다른 명령 등이 있습니다. 이러한 경우에는 시스템이 신뢰할 수 있다고 해도 안전하지 않을 수 있으며, 시스템이 사양에 따라 동작하더라도 사고를 일으킬 수 있습니다. 이런 이유로 안전과 신뢰성이 서로 연관되어 있지만 별개의 개념으로 취급되어야 합니다.

Safety-critical systems

Safety critical systems

• Systems where it is essential that system operation is always safe i.e. the system should never cause damage to people or the system’s environment
• Examples
  • Control and monitoring systems in aircraft
  • Process control systems in chemical manufacture
  • Automobile control systems such as braking and engine management systems

Safety critical systems

• 안전이 중요한 시스템은 항상 안전한 시스템 작동이 필수적인 시스템입니다. 즉, 시스템은 사람이나 시스템의 환경에 손상을 주지 않아야 합니다.
• 예시:
  • 항공기의 제어 및 모니터링 시스템
  • 화학 제조에서의 공정 제어 시스템
  • 자동차 제어 시스템 (브레이크 및 엔진 관리 시스템 등)

Hazards

• Situations or events that can lead to an accident
  • Stuck valve in reactor control system
  • Incorrect computation by software in navigation system
  • Failure to detect possible allergy in medication prescribing system
• Hazards do not inevitably result in accidents – accident prevention actions can be taken.

위험 (Hazards)

• 사고로 이어질 수 있는 상황이나 이벤트입니다.
  • 반응기 제어 시스템의 밸브 고장
  • 내비게이션 시스템 소프트웨어에서 잘못된 계산
  • 의약품 처방 시스템에서 알레르기 가능성 탐지 실패
• 위험은 필연적으로 사고를 초래하지 않습니다. 사고 예방 조치를 취할 수 있습니다.

Safety achievement

• Hazard avoidance
  • The system is designed so that some classes of hazard simply cannot arise.
• Hazard detection and removal
  • The system is designed so that hazards are detected and removed before they result in an accident.
• Damage limitation
  • The system includes protection features that minimise the damage that may result from an accident.

안전성 달성

• 위험 회피 (Hazard avoidance)
  • 시스템이 설계되어 일부 위험 범주가 발생하지 않도록 합니다.
• 위험 감지 및 제거 (Hazard detection and removal)
  • 시스템이 설계되어 위험이 사고로 이어지기 전에 감지되고 제거됩니다.
• 손상 제한 (Damage limitation)
  • 시스템에는 사고로 인한 손상을 최소화하는 보호 기능이 포함됩니다.

Safety terminology

Term	Definition
Accident(or mishap)	An unplanned event or sequence of events which results in human death or injury, damage to property, or to the environment. An overdose of insulin is an example of an accident.
Hazard	A condition with the potential for causing or contributing to an accident. A failure of the sensor that measures blood glucose is an example of a hazard.
Damage	A measure of the loss resulting from a mishap. Damage can range from many people being killed as a result of an accident to minor injury or property damage. Damage resulting from an overdose of insulin could be serious injury or the death of the user of the insulin pump.
Hazard severity	An assessment of the worst possible damage that could result from a particular hazard. Hazard severity can range from catastrophic, where many people are killed, to minor, where only minor damage results. When an individual death is a possibility, a reasonable assessment of hazard severity is ‘very high’.
Hazard probability	The probability of the events occurring which create a hazard. Probability values tend to be arbitrary but range from ‘probable’ (say 1/100 chance of a hazard occurring) to ‘implausible’ (no conceivable situations are likely in which the hazard could occur). The probability of a sensor failure in the insulin pump that results in an overdose is probably low.
Risk	This is a measure of the probability that the system will cause an accident. The risk is assessed by considering the hazard probability, the hazard severity, and the probability that the hazard will lead to an accident. The risk of an insulin overdose is probably medium to low

안전 용어 (Safety terminology)

용어	정의
사고 (또는 불운한 사건)	인명 사망이나 부상, 재산 피해 또는 환경에 미치는 결과를 초래하는 계획되지 않은 이벤트 또는 일련의 이벤트입니다. 인슐린 과다 투여는 사고의 예입니다.
위험	사고를 일으키거나 기여할 수 있는 잠재적인 조건입니다. 혈당을 측정하는 센서의 고장은 위험의 예입니다.
손상	불운한 사건으로 인한 손실의 측정치입니다. 손상은 사고로 인해 많은 사람이 사망하는 것부터 경미한 부상이나 재산 피해에 이르기까지 다양합니다.
위험 심각도	특정 위험으로부터 발생할 수 있는 최악의 손상을 평가합니다. 위험 심각도는 많은 사람이 사망하는 대형 사고에서부터 경미한 손상이 발생하는 사고에 이르기까지 다양합니다. 개별 사망 가능성이 있는 경우, '매우 높음'으로 위험 심각도를 평가하는 것이 합리적입니다.
위험 확률	위험을 초래하는 이벤트가 발생할 확률입니다. 확률 값은 임의적이지만 '있을 법한' (위험 발생 가능성이 1/100 정도)에서 '불가능성이 낮은' (위험이 발생할 만한 상황이 없다고 생각되는 경우)까지 다양합니다. 인슐린 펌프에서 과다 투여로 이어지는 센서 고장의 확률은 아마 낮을 것입니다.
리스크	시스템이 사고를 일으킬 확률을 측정하는 것입니다. 위험은 위험 확률, 위험 심각도, 그리고 위험이 사고로 이어질 확률을 고려하여 평가됩니다. 인슐린 과다 투여의 위험은 아마 중간에서 낮은 수준일 것입니다.

이러한 안전 용어는 안전 관련 시스템에서 발생할 수 있는 위험을 이해하고 평가하는 데 도움이 되며, 안전에 중점을 둔 설계와 프로세스를 구축하는 데 필수적입니다.

Safety requirements

Safety specification

• The goal of safety requirements engineering is to identify protection requirements,
  • and to ensure that system failures do not cause injury or death or environmental damage.
• Safety requirements may be ‘shall not’ requirements.
  • i.e. they define situations and events that should never occur.
• Functional safety requirements define:
  • Checking and recovery features that should be included in a system
  • Features that provide protection against system failures and external attacks

안전 명세

• 안전 요구 사항 공학의 목표는 보호 요구 사항을 식별하고 시스템 실패가 부상, 사망 또는 환경 피해를 초래하지 않도록 보장하는 것입니다.
• 안전 요구 사항은 '하지 말아야 할' 요구 사항일 수 있습니다. 즉, 절대 발생해서는 안 되는 상황과 이벤트를 정의합니다.
• 기능적 안전 요구 사항은 다음을 정의합니다.
  • 시스템에 포함되어야 하는 검사 및 복구 기능
  • 시스템 실패 및 외부 공격에 대한 보호를 제공하는 기능

Hazard-driven analysis

• Hazard identification
• Hazard assessment
• Hazard analysis
• Safety requirements specification

위험 기반 분석

• 위험 식별
• 위험 평가
• 위험 분석
• 안전 요구 사항 명세

Hazard identification

• Identify the hazards that may threaten the system.
• Hazard identification may be based on different types of hazard:
  • Physical hazards
  • Electrical hazards
  • Biological hazards
  • Service failure hazards
  • Etc.

위험 식별

• 시스템을 위협할 수 있는 위험을 식별합니다.
• 위험 식별은 다양한 유형의 위험에 기반할 수 있습니다.
  • 물리적 위험
  • 전기적 위험
  • 생물학적 위험
  • 서비스 실패 위험
  • 기타

Hazard assessment

위험 평가
위 그림은 위험 평가를 보여주며, 3단계로 나뉩니다.

허용할 수 없는 영역: 위험을 감수할 수 없습니다.
위험 감수 가능 영역: 위험을 줄이는 것이 실용적이지 않거나 비용이 많이 드는 경우에만 위험을 감수할 수 있습니다.
허용 가능한 영역: 위험이 낮아 허용 가능합니다.
(3) 밑에는 '하찮은 위험'이라는 글자가 있어서, 이 영역은 위험이 거의 없는 것을 의미합니다.

(2) 옆에 있는 ALARP 영역은 "As Low As Reasonably Practicable"을 의미합니다. 이 영역은 위험이 합리적으로 감소할 수 있는 한도 내에서 줄이려고 노력하는 것을 의미합니다. 이 영역에서는 추가적인 위험 감소 조치를 적용하여 위험을 낮추는 것이 목표입니다.

Social acceptability of risk

• The acceptability of a risk is determined by human, social and political considerations.
• In most societies, the boundaries between the regions are pushed upwards with time.
  • i.e.) society is less willing to accept risk.
  • For example, the costs of cleaning up pollution may be less than the costs of preventing it but this may not be socially acceptable.
• Risk assessment is subjective.
  • Risks are identified as probable, unlikely, etc.
  • This depends on who is making the assessment.

사회적 위험 인식

• 위험의 인식 여부는 인간, 사회, 정치적 고려 사항에 의해 결정됩니다.
• 대부분의 사회에서 시간이 지남에 따라 영역 간 경계가 점차 높아집니다.
  • 즉, 사회는 위험을 받아들이는 데 덜 유연해집니다.
  • 예를 들어, 오염을 처리하는 비용이 예방 비용보다 적을 수 있지만, 이는 사회적으로 받아들여지지 않을 수 있습니다.
• 위험 평가는 주관적입니다.
  • 위험이 '가능성이 있다', '있기 어렵다' 등으로 식별됩니다.
  • 이는 평가를 하는 사람에 따라 다릅니다.

Hazard assessment

• Estimate the risk probability and the risk severity.
• It is not normally possible to do this precisely so relative values are used such as ‘unlikely’, ‘rare’, ‘very high’, etc.
• The aim must be to exclude risks that are likely to arise or that have high severity.

위험 평가

• 위험 확률과 위험 심각도를 추정합니다.
• 일반적으로 정확하게 이를 수행하는 것이 불가능하므로 상대적인 값이 사용됩니다. 예를 들어 '있기 어렵다', '드문', '매우 높다' 등입니다.
• 목표는 발생 가능성이 높거나 심각도가 높은 위험을 배제하는 것입니다.

Hazard analysis

• Concerned with discovering the root causes of risks in a particular system.
• Techniques have been mostly derived from safety-critical systems and can be
  • Inductive, bottom-up techniques
    • Start with a proposed system failure and assess the hazards that could arise from that failure.
    • e.g.) Design Failure Modes and Effects Analysis (DFMEA)
• Deductive, top-down techniques
  • Start with a hazard and deduce what the causes of this could be.
  • e.g.) Fault Tree Analysis (FTA)

위험 분석

• 특정 시스템에서 위험의 근본 원인을 찾아내는 것에 관심이 있습니다.
• 기법은 대부분 안전 관련 시스템에서 유래되었으며 다음과 같은 것이 있습니다.
  • 유도적, 바닥부터 시작하는 기법
    • 제안된 시스템 실패로 시작하여 해당 실패로 인해 발생할 수 있는 위험을 평가합니다.
    • 예) 설계 실패 모드 및 효과 분석 (DFMEA)
  • 연역적, 상향식 기법
    • 위험으로 시작하여 그 원인이 될 수 있는 것을 추론합니다.
    • 예) 결함 트리 분석 (FTA)

Risk reduction

• The aim of this process is to identify dependability requirements that specify how the risks should be managed and ensure that accidents/incidents do not arise.
• Risk reduction strategies
  • Hazard avoidance;
  • Hazard detection and removal;
  • Damage limitation.

위험 감소

• 이 과정의 목표는 위험 관리 방법을 지정하는 신뢰성 요구 사항을 식별하고 사고/사건이 발생하지 않도록 보장하는 것입니다.
• 위험 감소 전략
  • 위험 회피;
  • 위험 탐지 및 제거;
  • 피해 제한.

Strategy use

• Normally, in critical systems, a mix of risk reduction strategies are used.
  • In a chemical plant control system, the system will include sensors to detect and correct excess pressure in the reactor.
  • However, it will also include an independent protection system that opens a relief valve if dangerously high pressure is detected.
• Having redundancy and diversity is often crucial to risk reduction.

전략 사용

• 일반적으로 중요한 시스템에서는 위험 감소 전략의 조합이 사용됩니다.
  • 예를 들어, 화학 공장 제어 시스템에서는 반응기 내 과도한 압력을 감지하고 수정하기 위해 센서가 포함됩니다.
  • 그러나 독립적인 보호 시스템도 포함되어 있어, 위험하게 높은 압력이 감지되면 안전 밸브가 열립니다.
• 중복성과 다양성은 종종 위험 감소에 중요한 역할을 합니다.

위험 감소 전략을 사용하면 중요한 시스템에서 안전성을 향상시킬 수 있습니다. 여러 전략을 적용하여 위험을 관리하고, 시스템이 안전하게 작동하도록 할 수 있습니다. 중복성과 다양성을 도입함으로써, 특정 구성 요소가 실패하더라도 다른 구성 요소가 시스템의 안전을 유지하는 데 도움이 됩니다.

Safety engineering processes

Safety engineering processes

• Safety engineering processes are based on reliability engineering processes:
  • Plan-based approach with reviews and checks at each stage in the process.
  • General goal of fault avoidance and fault detection.
  • Must also include safety reviews and explicit identification and tracking of hazards.

안전 공학 프로세스

• 안전 공학 프로세스는 신뢰성 공학 프로세스를 기반으로 합니다:
  • 각 단계에서 검토 및 확인이 있는 계획 기반 접근 방식
  • 오류 방지 및 오류 탐지를 일반 목표로 함
  • 안전 검토와 명시적인 위험 식별 및 추적도 포함해야 합니다.

Regulation

• Regulators may require evidence that safety engineering processes have been used in system development
• For example:
  • The specification of the system that has been developed and records of the checks made on that specification.
  • Evidence of the verification and validation processes that have been carried out and the results of the system verification and validation.
  • Evidence that the organizations developing the system have defined and dependable software processes that include safety assurance reviews.
    • There must also be records that show that these processes have been properly enacted.

규제

• 규제 기관은 시스템 개발에서 안전 공학 프로세스가 사용된 증거를 요구할 수 있습니다.
• 예를 들어:
  • 개발된 시스템의 사양 및 해당 사양에 대해 수행된 검사 기록
  • 수행된 검증 및 검증 프로세스에 대한 증거와 시스템 검증 및 검증 결과
  • 시스템을 개발하는 조직이 안전 보증 검토를 포함하는 정의되고 신뢰할 수 있는 소프트웨어 프로세스를 갖추고 있다는 증거
    • 이러한 프로세스가 제대로 실행되었음을 보여주는 기록도 있어야 합니다.

Safety assurance processes

• Process assurance involves defining a dependable process and ensuring that this process is followed during the system development.
• Process assurance focuses on:
  • Do we have the right processes?
    • Are the processes appropriate for the level of dependability required? Should include requirements management, change management, reviews and inspections, etc.
  • Are we doing the processes right?
    • Have these processes been followed by the development team.
  • Process assurance generates documentation.
    • Agile processes therefore are rarely used for critical systems.

안전 보증 프로세스

• 프로세스 보증은 신뢰할 수 있는 프로세스를 정의하고 시스템 개발 동안 이 프로세스를 따르는 것을 보장하는 것입니다.
• 프로세스 보증은 다음에 초점을 맞춥니다:
  • 올바른 프로세스를 갖고 있는가?
    • 프로세스가 필요한 신뢰성 수준에 적합한가? 요구 사항 관리, 변경 관리, 검토 및 검사 등이 포함되어야 합니다.
  • 프로세스를 올바르게 수행하고 있는가?
    • 개발 팀이 이러한 프로세스를 따랐는지 확인합니다.
• 프로세스 보증은 문서를 생성합니다.
  • 따라서, 애자일 프로세스는 일반적으로 중요한 시스템에는 사용되지 않습니다.

Safety related process activities

• Hazard Analysis: involves identifying hazards and their root causes.
• There should be clear traceability from identified hazards through their analysis
  • to the actions taken during the process to ensure that these hazards have been covered.
  • A hazard log may be used to track hazards throughout the process.
• Safety Review: Driven by the hazard register.
  • For each identified hazard, the review team should assess the system and judge whether or not the system can cope with that hazard in a safe way.

안전 관련 프로세스 활동

• 위험 분석: 위험과 그 근본 원인을 식별하는 것을 포함합니다.
• 식별된 위험으로부터 그 분석을 통해
  • 이러한 위험에 대처하기 위해 프로세스 동안 취해진 조치에 대한 명확한 추적성이 있어야 합니다.
  • 위험 기록지를 사용하여 프로세스 전체에서 위험을 추적할 수 있습니다.
• 안전 검토: 위험 등록부에 의해 주도됩니다.
  • 각각의 식별된 위험에 대해 검토 팀은 시스템을 평가하고 해당 위험을 안전하게 처리할 수 있는지 여부를 판단해야 합니다.

Formal verification

• Formal methods can be used when a mathematical specification of the system is produced.
• They are the ultimate static verification technique that may be used at different stages in the development process:
  • A formal specification may be developed and mathematically analyzed for consistency.
    • This helps discover specification errors and omissions.
  • Formal arguments that a program conforms to its mathematical specification may be developed.
    • This is effective in discovering programming and design errors.
• It is not widely used, since it is very expensive and similar level of confidence can be achieved by other methods.

형식적 검증

• 형식적 방법은 시스템의 수학적 명세가 작성될 때 사용할 수 있습니다.
• 이들은 개발 프로세스의 다양한 단계에서 사용할 수 있는 최종 정적 검증 기술입니다:
  • 형식적 명세를 개발하고 일관성을 위해 수학적 분석을 수행할 수 있습니다.
    • 이를 통해 사양 오류와 누락을 발견할 수 있습니다.
  • 프로그램이 수학적 명세에 부합하는지에 대한 형식적 논증을 개발할 수 있습니다.
    • 이를 통해 프로그래밍 및 설계 오류를 발견하는데 효과적입니다.
• 널리 사용되지는 않지만 매우 비싸기 때문에 그렇습니다. 비슷한 수준의 신뢰성은 다른 방법을 사용하여 달성할 수 있습니다.

Model checking

• Involves creating an extended finite state model of a system and, using a specialized system (a model checker), checking that model for errors.
• The model checker explores all possible paths through the model and checks that a user-specified property is valid for each path.
• Model checking is particularly valuable for verifying concurrent systems, which are hard to test.
• Although model checking is computationally very expensive, it is now practical to use it in the verification of small to medium sized critical systems.

모델 체킹

• 시스템의 확장된 유한 상태 모델을 작성하고, 전문 시스템(모델 검사기)을 사용하여 모델의 오류를 검사하는 것을 포함합니다.
• 모델 검사기는 모델의 모든 가능한 경로를 탐색하고 사용자가 지정한 속성이 각 경로에 대해 유효한지 확인합니다.
• 모델 체킹은 테스트하기 어려운 동시성 시스템을 검증하는 데 특히 유용합니다.
• 모델 체킹은 계산적으로 매우 비용이 많이 들지만, 현재 소규모에서 중규모 크기의 중요한 시스템을 검증하는 데 사용하는 것이 현실적입니다.

Static program analysis

• Static analysers are software tools for source text processing.
• They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team.
• They are very effective as an aid to inspections - they are a supplement to but not a replacement for inspections.

정적 프로그램 분석

• 정적 분석기는 소스 텍스트 처리를 위한 소프트웨어 도구입니다.
• 프로그램 텍스트를 구문 분석하고 잠재적으로 잘못된 조건을 찾아내어 V & V 팀에 알립니다.
• 검사를 돕는 데 매우 효과적입니다. 검사를 대체하는 것이 아니라 보완하는 역할을 합니다.

Levels of static analysis

• Characteristic error checking
  • The static analyzer can check for patterns in the code that are characteristic of errors made by programmers using a particular language.
• User-defined error checking
  • Users of a programming language define error patterns, thus extending the types of error that can be detected. This allows specific rules that apply to a program to be checked.
• Assertion checking
  • Developers include formal assertions in their program and relationships that must hold. The static analyzer symbolically executes the code and highlights potential problems.

정적 분석의 수준

• 특성 오류 검사
  • 정적 분석기는 특정 언어를 사용하는 프로그래머가 범하는 오류의 특성을 가진 코드 패턴을 검사할 수 있습니다.
• 사용자 정의 오류 검사
  • 프로그래밍 언어 사용자가 오류 패턴을 정의하여 감지할 수 있는 오류 유형을 확장합니다. 이를 통해 프로그램에 적용되는 특정 규칙을 확인할 수 있습니다.
• 단언 검사
  • 개발자들은 프로그램에 형식적인 단언과 유지되어야 하는 관계를 포함시킵니다. 정적 분석기는 코드를 기호적으로 실행하고 잠재적인 문제를 강조합니다.

Use of static analysis

• Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler.
• Particularly valuable for security checking.
  • The static analyzer can discover areas of vulnerability such as buffer overflows or unchecked inputs.
• Static analysis is now routinely used in the development of many safety and security critical systems.
  • Clang (C/C++), FindBugs (Java), ESLint (Javascript), Pylint (Python), Coverity, SonarQube, etc.

정적 분석의 사용

• C와 같은 약한 타입을 가진 언어가 사용될 때 특히 유용하며, 따라서 많은 오류가 컴파일러에서 감지되지 않습니다.
• 보안 검사에 특히 유용합니다.
  • 정적 분석기는 버퍼 오버플로우나 검사되지 않은 입력과 같은 취약한 영역을 발견할 수 있습니다.
• 정적 분석은 현재 많은 안전 및 보안 중심 시스템 개발에 일반적으로 사용되고 있습니다.
  • Clang (C/C++), FindBugs (Java), ESLint (Javascript), Pylint (Python), Coverity, SonarQube 등과 같은 도구들이 있습니다.

정적 분석은 소프트웨어 개발에서 오류를 찾아내고, 시스템의 안전성과 보안성을 향상시키는 데 도움을 주는 기술입니다. 이러한 도구들은 개발 프로세스에 통합되어 프로그램의 품질을 향상시키고, 잠재적인 문제를 조기에 발견하여 개발 팀이 수정할 수 있도록 합니다. 이를 통해 안전 및 보안에 중요한 시스템의 신뢰성과 견고성이 향상됩니다.