New paradigm of software by AI. nondeterminism problem in safety critical system(AI에 의한 소프트웨어의 새로운 패러다임. safety critical system에서의 nondeterminism문제)

한글버전은 아래로.Korean version is below.

When I studied the formal specification at the time of my Ph.D., I considered the deterministic nature of the system to be very important in terms of predictability and testability of the system. I do not think anyone would ever want to put a system into a system that does not know where to go.

A system based on AI can not perform an exhaustive test by default. However, in an exceptional situation that has not been tested, the system can not know what to do.

Therefore, the test will inevitably reach its limit.

So what should you do?

Formal verification is required. The most important thing when formal verification was done is the accuracy and sufficiency of the specification. It is not easy to judge whether or not you have written this formally. Well, even if it is better than test.

You should verify on the line considering both formal verification and testing. The most important thing here is that you have to define the safety attributes formally and the run-time verifier should continue monitoring whether the attributes are maintained. This is not a test. And it will be impossible for all situations to be tested, and a separate supervisor should be software in a way that defines the boundary of the system’s behavior space and makes it behave in it.

In the old days, everything was checked as it was intended. In the meantime, the developer has created a fatalistic system. He knows everything about what to do in 10 seconds. But AI will not be able to manage it in the future.

The problem also comes down to how AI will not be dominated in the future. It may be a concern at this point, but it will not be a distant future for such concerns to come true.

The IEEE is doing some interesting work on this. I think we should be interested in the future.

Ethically Aligned Design: Prioritizing Wellbeing for Artificial Intelligence and Autonomous Systems

박사과정때 Formal specification에 대해 연구했을때, 시스템의 예측 가능성과 테스트 가능성의 관점에서 시스템의 deterministic한 속성은 매우 중요하다고 생각했다. 어디로 튈지 모르는 시스템을 만들어놓고, 그 시스템에 자기의 목숨을 걸고 싶은 사람은 없을거라 생각한다.

AI에 의한 시스템은 기본적으로 test에 의해 exhaustive test를 수행하지 못한다. 그러나 미처 시험하지 않은 예외적 상황에서 시스템이 어떤 행동을 할 지 알 수 없다.

그러므로, test는 불가피하게도 한계를 맞이할 수 밖에 없을 것이다.

그러면 무엇을 해야 할 것인가?

formal verification을 해야 한다. formal verification을 수행했을 당시 가장 중요한 것은 specification의 정확성과 충분성이다. 과연 이 정도로 formal하게 기술했느냐를 판단하는 것이 쉽지 않다. 뭐, 그렇긴 하더라도 test보다야 낫다.

formal verification과 test의 양쪽을 다 고려해서 run-time verification을 해야 한다. 여기서 가장 중요한 것은 safety에 의한 속성을 잘 정의해야 하고, 그 속성이 유지되는지를 run-time verifier는 모니터링을 계속해야 할 것이다. 이것은 시험이 아니다. 그리고 모든 상황을 고려한 시험은 이제 불가능하게 될 것이고, 별도의 supervisor가 시스템의 행동 space의 boundary를 정하고 그 안에서 행동하도록 하는 방식의 소프트웨어가 되어야 할 것이다.

예전에는 모든 것을 의도한대로 일일이 다 점검했다. 그동안 개발자는 운명론적인 시스템을 만들어서 1초 뒤에, 10초 뒤에 어떤 일을 할 지에 대해서 모든 것을 알 수 있었다. 하지만 AI에 의해 앞으로 그런 방식의 관리는 불가능하게 될 것이다.

이 문제는 또한 향후 AI를 어떻게 감시해야 AI의 지배를 받지 않게 될 것인가하고도 맞닿아 있다. 현재 시점에서는 우려일 수 있으나, 그런 우려가 현실이 되는 것은 그리 먼 미래가 아닐 것이다.

IEEE에서 이와 관련된 흥미로운 작업을 하고 있다. 앞으로 관심을 가져야 할 것이라 생각한다.

Ethically Aligned Design: Prioritizing Wellbeing for Artificial Intelligence and Autonomous Systems

Unit testing is useless in some aspects(단위 시험은 어떤 측면에서 쓸데없다)

한글버전은 아래로..

I think the title is somewhat irritating. I admit it. It is an exaggerated expression. But it is also true.

I think there is nothing better than a unit test. It is a very good practice if you have completed the unit test to see if you are doing what you intended to do.

But if you think about the quality of the product by a third party, the position will change. In a real consulting project, I found that it is quite tricky for a third party auditor to make a technical assessment of this part.

That’s true.

When we say that the coverage measurement is not a coverage analysis, the unit test ‘s uselessness shines. For example, suppose you create a calculator program that has an add / subtract function. In terms of coverage, 1 + 1, 1-1, 1/1, 1 * 1 will achieve 100% by default.

But …. Do you think you will use the test procedure and write the test results in a normal unit test? Or do you think you will see the test results and change the test procedure? Eh ? What are you talking about?

In the process, it is important to write a test procedure, to test it, to get test results, and to review the results. But ……………. There might be a developer who does not …

It is possible to use a trick somewhat different from the intended direction in the standard. However, the problem is that it is very difficult to carry out a technical examination of this part in the case of a unit test. Is it possible for a third party assessor to understand and check the logic of your code ?

What’s even worse is that there is a shortcut to achieve this if you have a goal to achieve 100% of MC / DC as well as code coverage … This is not the intention of the person who originally thought of this method.

This leads to the conclusion that it is not possible to check whether the unit test was carried out with authenticity. It is not that much if it is aimed at making sure that one trick is properly passed through one by one. Besides, it’s hard for the assessor to catch that part.

If then, why we have to force unit test?

In that respect, the requirement based test method overcomes this problem. In addition, it is possible to check how well the requirements are written, and the examination of the test procedures and the results of those parts can be better done.

From that point of view, standards that require unit testing need to be refreshed

 

제목이 약간 자극적이라는 생각이 든다. 인정한다. 과장된 표현이다. 하지만, 사실이기도 하다.

단위 시험을 제대로 한다면 그것만큼 훌륭한 툴은 없다고 생각한다. 설계자의 의도에 맞는 행동을 하는지의 여부를 단위시험까지 완벽하게 되었다면 매우 훌륭한 practice임에는 틀림이 없다.

하지만 제3자가 그 제품에 대한 quality를 평가해야 하는 입장에서 생각해보면 입장이 달라진다. 실제 컨설팅 프로젝트에서 이 부분에 대해 제 3자 auditor가 이 부분에 대한 기술적인 평가를 하는 것이 상당히 까다롭다는 것을 발견했다.

실제로 그렇다.

coverage analysis가 아닌 coverage 측정 행위를 한다고 했을때, unit 시험의 무용론은 빛을 발하게 된다. 예를 들어 가감승제 기능이 있는 연산기 프로그램을 만든다고 가정하자. coverage 관점에서 1+1, 1-1, 1/1, 1*1을 하면 기본적으로 100%를 달성하게 될 것이다.

그런데…. 보통의 단위 시험을 시험 절차를 쓰고 시험 결과를 쓴다고 생각하는가? 아니면 시험 결과 나온 것을 보고 시험 절차를 변경한다고 생각하는가? 엥 ? 이게 무슨 소리냐고?

프로세스 상으로는 시험 절차를 쓰고, 시험을 해서 시험 결과가 나오고, 그 결과를 검토하는 것이 정석이다. 그런데……………. 그렇게 하지 않는 개발업체도 있을 수 있다는 말이다…

표준에서 의도했던 방향과는 약간 다르게 trick을 쓸 수 있는 것이다. 그런데, 문제는 단위 시험의 경우 이 부분에 대한 기술적 검토를 하는 것이 굉장히 어렵다는 것이다. 코드의 로직을 다 이해하고 점검해야 하는데, 과연 제 3자 평가자가 그 정도까지 할까?

게다가 더 최악인 점은…. Code coverage뿐만 아니라 MC/DC까지도 100%를 달성하고자 하는 목표만 있다면, 이를 달성하기 위한 지름길이 있다는 점이다… 이 또한 당초 이 방법을 생각한 사람의 의도한 것이 아닐 것이다.

상황이 이렇다보니 unit test에 대한 진정성을 가지고 수행했는지에 대한 점검이 원천적으로 불가능하다는 결론에 다다르게 된다. 어차피 꼼수로 하나 제대로 하나 통과받도록 하기 위한 목적이라면 별것도 아니라는 얘기다. 게다가 평가자가 그 부분을 잡기도 힘들고..

그럴거면 unit test라는 것을 왜 억지로 하도록 해야 하냐 이거다.

그런 점에서 requirement based test방법은 이런 문제점을 극복한다. 게다가 requirement가 얼마나 잘 작성되었는지를 점검할 수도 있으며, 그 부분에 대한 시험 절차와 결과의 검토가 더 잘 이루어질 수 있다.

그런점에서 봤을때, unit test를 요구하는 표준들은 좀 반성을 해야 할 필요가 있다고 생각한다…

 

Structural Coverage만 만족시키려고 하는 것 혹은 그것도 맞추지 못하는 것에 대해

구조적 coverage만 100%달성하면 뭔가 제대로 한 것처럼 생각하는 사람들, 그리고 그것조차도 맞추기 힘들다고 생각하는 사람들을 위한 글이다.

그런 표현들을 아무렇지도 않게 하는 사람들이 있다. 잘 모르시는 말씀이다. 만약 그것이 문제라면 단번에 무력화시킬 수 있는 파워치트가 있다. 그렇기 때문에 구조적 커버리지에만 포커스를 두면 절대 안된다.

근데, 그런거 잘 모르는 사람들은 coverage 100%만 달성하면 모든게 끝난줄 안다. 방금 얘기했듯이 파워치트가 있다고 했다. 그까짓꺼 그냥~ 하고 무력화시킬 수 있다.

그러니까 구조적 커버리지 그거 맞추지도 못한다, 혹은 현실적으로 불가능하다 라는 소리는 제발 하지 않았으면 좋겠다. 그건 기본중의 기본이다. 커버리지 플러스 알파를 해야 하는 마당에 …