Summarize the following into 10 bullet points:
Title: The Ariane 5 bug and a few lessons
Author: Les Hatton, Oakwood Computing, U.K. and the Computing Laboratory,
University of Kent, UK.
TOC: A fascinating example of a problem caused by a strength in a programming
language and not a weakness.
ARTICLE:
On the 4th June, 1996, the maiden flight of the Ariane 5 launcher ended after 40
seconds with the launcher spread over a fairly large part of Kourou, greatly
depressing the market in tiny pieces of launch vehicle. The enquiry board
responded with commendable speed and on the 19th July, a report came out
describing its deliberations and conclusions and fascinating reading it makes too.
This incident is one of a wide class of famous failures based on precision
problems, (one of these was responsible for the Patriot missile failure in the Gulf
War in 1991 which led to the death of 29 people; another led to the Bank of New
York having to borrow $24 billion for a day from the Federal Reserve a few years
ago). The interesting thing about this class of problem is that they are generally
statically detectable and are therefore highly avoidable.
In the case of Ariane 5, the programmers had arranged the code such that a 64 bit
floating point number was shoe-horned into a 16-bit integer. This is not easy in
Ada, the programming language used, in fact you have to override the compiler’s
objections to achieve it, so they did. There were seven such occasions but only
four of them protected against the possibility of overflow. The other three were not
protected because the programmers thought they could never overflow. They were
wrong. Now it gets interesting.
The offending piece of software was actually re-used from Ariane 4, (re-use was
also implicated in the tragic software failure in Therac-25 which led to the death of
3 people after severe radiological overdose). In fact, this piece of software had no
relevance to the flight of Ariane 5, its use ceasing at the point of lift-off. However, it
continued to run. Approximately 37 seconds into the flight, the 16-bit integer
overflowed. Now in a sloppier language like C, the program would have continued
happily rumbling away to itself but would not in all probability have interfered with
the flight. However, the Ada language is made of sterner stuff. Faced with this runtime exception, the program threw an exception as any reasonable language
should in such a situation. The programmers did not handle the exception
because the assumption was made that the program was correct until proved at
fault, apparently a feature of the programming culture for this system, (this
observation is worth an article in itself). The default action was regrettably to close
the system down, including other components which were critical.
At this point, Ariane 5 then demonstrated the fundamental weakness of restricted 2-
way diversity. The offending piece of software runs in an SRI (Inertial Reference
System) of which there are two, a primary system and a ‘hot’ back-up. When the
first fails, the backup jumps in and takes over. Each SRI duplicates the hardware
and the software. When the primary SRI closed down, the backup SRI took over
and not surprisingly, failed for the same reason 72 msec. later. From this point on,
Ariane 5 assumed the aerodynamic properties of an overhead projector and shortly
afterwards turned it self into 12 km. of debris.
What can we learn from this ? There are several lessons:-
a) Type and precision mismatching is once again identified as a primary
source of computer systems failure. For compilers which do not warn
adequately of such precision faults, they are often statically detectable by
reasonable tools. In stronger typed languages, for example, Ada, you
actually have to go to significant lengths even to circumvent the compiler’s
objections to this dangerous practice. For the Ariane 5 programmers to
subvert this apparently on the grounds that they can avoid problems by
reasoning alone seems highly questionable.
b) Re-use without very detailed re-analysis can be a dangerous de-stabiliser of
systems behaviour. Re-use is considered one of the great hopes of modern
software engineering, but if you re-use a component inappropriately or you
re-use a faulty component, the system certainly isn’t going to get better.
There are enough examples of this happening to cast considerable doubt on
our current understanding of re-use.
c) Diverse systems running the same software are effectively useless given
that the average piece of hardware is much more reliable than any software.
Look at PCs for example, where a hard disc has a mean time between
failures of around 1,000,000 hours these days, whereas the hapless
Windows falls over with a mean failure time of a few hours, (minutes if you
are doing software development). (This also gives me the chance to repeat
something I have been saying for two years now and is becoming more and
more obvious. Linux appears to be at least 2 orders of magnitude more
reliable than any form of Windows, so it is possible to produce robust
software).
d) Lastly, and the point I’m really coming to, is that the programming language
is only one part of the jigsaw of systems behaviour. Here, a strength of the
Ada language, inappropriately handled led directly to the spectacular failure,
where a sloppier language might not have. The lesson here is that it is not
so much the programming language which is important as the programmer’s
fluency in whatever language is in use and reasoning about systems
behaviour from the point of view of the language alone can be a
dangerously misleading practice.
Finally, I understand that because this was the first launch, some of the payload
satellites travelled for free, which just goes to show that there is no such thing as a
free launch.
AUTHOR BIO:
Les Hatton has been suffering from computer systems for 30 years. He is a
software consultant and Professor of Software Reliability at the University of Kent.
In October 1998, he was named in the ‘world’s leading 15 scholars of systems and
software engineering’ by the US Journal of Systems and Software.
SIDEBARS:
None.
다음 내용을 10개의 글머리 기호로 요약하세요:제목: Ariane 5 버그와 몇 가지 교훈저자: 작성자: 레 해튼, 영국 오크우드 컴퓨팅 및 컴퓨팅 연구실,영국 켄트 대학교.개요: 프로그래밍 언어의 약점이 아닌 강점으로 인해 발생한 문제의 흥미로운 예입니다.약점이 아닌 프로그래밍 언어의 강점으로 인한 문제의 흥미로운 예입니다.기사:1996년 6월 4일, 아리안 5 발사체의 처녀 비행은 40초 만에 끝났습니다.발사기가 쿠루의 상당히 넓은 지역에 퍼져있는 초, 크게발사체의 작은 조각으로 시장을 우울하게 만들었습니다. 문의 게시판는 놀라운 속도로 대응했고, 7월 19일에 보고서가 발표되었습니다.심의와 결론을 설명하는 보고서가 나왔는데, 그 내용도 흥미로웠습니다.이 사건은 정밀도에 기반한 다양한 종류의 유명한 실패 중 하나입니다.문제, (이 중 하나는 걸프전에서 패트리어트 미사일 실패의 원인이었습니다.1991년 걸프전에서의 패트리어트 미사일 실패로 29명이 사망했고, 또 다른 실패로 인해 뉴욕 은행이 240억 달러를 빌려야 했습니다.뉴욕 은행은 몇 년 전 연방 준비 은행으로부터 하루 동안 240억 달러를 빌려야 했습니다.전). 이러한 종류의 문제에서 흥미로운 점은 일반적으로 다음과 같습니다.정적으로 탐지할 수 있으므로 피할 수 있다는 것입니다.아리안 5의 경우, 프로그래머들은 64비트 부동 소수점 숫자가부동 소수점 숫자가 16비트 정수로 변환되도록 코드를 배열했습니다. 이것은 쉬운 일이 아닙니다.사용되는 프로그래밍 언어인 Ada에서는 컴파일러의 이의제기를 무시해야 하므로컴파일러의 이의제기를 무시해야 하기 때문에 그렇게 했습니다. 그런 경우가 7번 있었지만네 번만 오버플로 가능성을 방지했습니다. 나머지 세 건은 보호되지 않았습니다.프로그래머가 오버플로가 절대 일어나지 않을 것이라고 생각했기 때문입니다. 그들은틀렸습니다. 이제 흥미로워집니다.문제가 된 소프트웨어는 사실 아리안 4에서 재사용된 것이었습니다.재사용은 또한 Therac-25의 비극적 인 소프트웨어 오류와 관련이 있습니다.심각한 방사선 과다 복용 후 3명이 사망했습니다). 사실 이 소프트웨어는아리안 5의 비행과 관련이 없으며, 이륙 시점에 사용이 중단되었습니다. 하지만계속 실행되었습니다. 비행 약 37초 후, 16비트 정수가가 넘쳤습니다. C와 같은 더 조잡한 언어였다면 프로그램은 계속 실행되었을 것입니다.행복하게 혼자서 울부짖었을 테지만, 비행을 방해하지는 않았을 것입니다.비행을 방해하지 않았을 것입니다. 하지만 Ada 언어는 더 엄격하게 만들어졌습니다. 이 런타임 예외에 직면한 프로그램은 이러한 상황에서 모든 합리적인 언어가 해야 할예외를 던졌습니다. 프로그래머는 예외를 처리하지 않았습니다.잘못이 증명될 때까지 프로그램이 올바르다고 가정했기 때문입니다.결함, 분명히이 시스템의 프로그래밍 문화의 특징 인 것 같습니다 (이관찰은 그 자체로 기사 가치가 있습니다). 유감스럽게도 기본 조치는 시스템을 닫는 것이었습니다.중요한 다른 구성 요소를 포함하여 시스템을 종료했습니다.이 시점에서 Ariane 5는 제한된 2가지 방법의 근본적인 약점을 보여주었습니다.방법의 다양성. 문제가 된 소프트웨어는 두 가지가 있는 SRI(관성 참조시스템)에서 실행되며, 기본 시스템과 '핫' 백업이 두 개 있습니다. 기본 시스템이먼저 장애가 발생하면 백업이 들어와서 이를 대신합니다. 각 SRI는 하드웨어와 소프트웨어를 복제합니다.소프트웨어를 복제합니다. 기본 SRI가 종료되면 백업 SRI가 그 역할을 대신합니다.그리고 놀랍게도 72밀리초 후에 같은 이유로 실패했습니다. 이 시점부터아리안 5는 오버헤드 프로젝터의 공기역학적 특성을 가정하고 곧바로얼마 지나지 않아 스스로 12km의 파편으로 변했습니다.이로부터 무엇을 배울 수 있을까요? 몇 가지 교훈이 있습니다.a) 유형 및 정밀도 불일치가 컴퓨터 시스템 고장의 주요컴퓨터 시스템 오류의 원인으로 다시 한 번 확인되었습니다. 이러한 정밀도 결함을 경고하지 않는 컴파일러의 경우이러한 정밀도 오류는 종종 정적으로 감지할 수 있는합리적인 도구. 예를 들어 Ada와 같이 강력한 타이핑 언어에서는컴파일러를 우회하기 위해서도 상당한 노력을 기울여야 합니다.이 위험한 관행에 대한 이의 제기. 아리안 5 프로그래머가문제를 피할 수 있다는 이유로 이를 무시하는 것은추론만으로 문제를 피할 수 있다는 이유로 이를 뒤집는 것은 매우 의심스러워 보입니다.b) 매우 상세한 재분석 없이 재사용하는 것은 시스템 동작의시스템 동작을 불안정하게 만들 수 있습니다. 재사용은 현대 소프트웨어 엔지니어링의 큰 희망 중 하나로 간주됩니다.하지만 구성 요소를 부적절하게 재사용하거나 결함이 있는 구성 요소를결함이 있는 구성 요소를 재사용하면 시스템이 개선되지 않을 것입니다.재사용에 대한 현재의 이해에 상당한 의문을 제기하기에 충분한 사례가재사용에 대한 우리의 현재 이해에 상당한 의구심을 불러일으키기에 충분한 사례입니다.c) 동일한 소프트웨어를 실행하는 다양한 시스템은 사실상 쓸모가 없습니다.평균적인 하드웨어는 어떤 소프트웨어보다 훨씬 더 안정적입니다.예를 들어 하드 디스크의 평균 고장 간격이 약 1,000,000회인 PC를 생각해보십시오.약 1,000,000시간의 장애가 발생하는 반면, 불운하게도Windows는 평균 고장 시간이 몇 시간(소프트웨어 개발을 하는 경우 몇 분)에 불과합니다.소프트웨어 개발을 하고 있다면 몇 분). (이것은 또한 제가 2 년 동안 반복 할 수있는 기회를 제공합니다.제가 2 년 동안 말해온 것을 반복 할 수있는 기회를 제공합니다.더 분명해졌습니다. Linux는 최소 2단계 이상 높은 것으로 보입니다.