No real time schedule analysis


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, 그 중에서 Engineering적인 측면에서 관심있는 것 중 하나를 골라서 서술하고자 한다.

15. No real time schedule analysis

Real time scheduling방식에는 여러가지 방식이 있다. 그 중에서 Rate monotonic 방식은 cost대비 가장 효과적인 것으로 알려져있다.  그런데 회사에서 어떤 알고리즘을 사용하냐고 물어보면 cyclic executives방식을 사용한다고들 한다. 그 이유는 RM방식이 cyclic executive방식보다 직관적이지 않고 분석하기가 쉽지 않기 때문인 것 같다. Rate monotonic방식과 cyclic executive방식에 대한 장단점은 논문 Software Architecture for Hard Real-Time Applications; Cyclic Executives vs. Fixed Priority Executives에 정리되어 있다.

functional safety관점에서는 rate monotonic을 무작정 사용하는 것도 쉽지는 않을 수 있는데, 이유는 여러가지 ASIL을 가진 software의 scheduling시에 낮은 ASIL이 높은 ASIL에게 간섭할 수 있기 때문인데 이와 관련된 논문이 Applying the AUTOSAR timing protection to build safe and efficient ISO 26262 mixed-criticality systems이다. 그런데 이 글을 쓰면서 갑자기 든 생각은, 여러가지 ASIL을 가진 software의 scheduling이 현실적인가? 란 의문이 들기도 한다. partitioning이 되어 있다면 여러 종류의 ASIL을 가진 task간 scheduling은 가능할 것이긴 한데, 이건 나중에 별도의 글로 작성할 기회가 되면 작성하도록 하겠다.

 

real time scheduling을 design하기 위해서는 task를 정의하고 각 task가 달성해야 하는 목표를 수집한다. 예를 들면 task1은 100msec마다 수행되어야 한다는 것이라던지, task2는 200msec마다 수행되어야 한다는 것이겠다. plan에서는 task의 이름, period, 우선순위, maximum execution time등이 기술되어야 한다. maximum execution time을 정의하기 위해서는 상당히 보수적인 관점에서 정의해야 할 필요가 있다. 즉 Worst case execution time(WCET)를 알아야 한다. 현실적으로 정확한 값을 구하기가 어렵다면 어느정도 buffer를 두거나 정말 재수가 없어도 정말 없을 만한 상황을 고려하여 기술하면 될 것이다. (broken pipeline, missed cache, page fault)

scheduling plan을 세웠으면 분석을 통해 그 plan이 실현 가능한지의 여부를 판단해야 한다. 이 때 사용하는 방법이 real time schedule analysis방법이다.

scheduling plan을 세우기 전에 각 scheduling방법의 장단점을 숙지해야 하고, 전략을 짜야 한다. scheduling을 어떻게 짜느냐에 따라서 프로그램의 구조가 많이 달라질 수 있기 때문에 소프트웨어 설계에서 매우 중요하다.

 

Advertisements

Flowcharts are used in place of statecharts


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, Engineering적인 측면에서 관심있는 것 중 하나를 선택해서 글을 쓰고자 한다.

11. Flowcharts are used in place of statecharts

Statecharts(혹은 stateflow)는 상태에 따라 다른 behavior를 기술해야 할 필요가 있을 때 기술하면 좋은 방법이고 flowchart는 상태에 따른 behavior를 기술해야 할 필요가 없을 때 기술하면 좋은 방법이다.

예를 들어서 설명하는 모든 경우에 대해 어떤 입력이 들어올 때 항상 동일한 행동을 해야 하는 경우라면 그건 상태 정보가 필요하지 않은 경우이다. 그 때에는 flowchart로 표현하는 것이 더 좋다.

1

 

위의 flowchart는 activation이 되면 항상 시작에서 종료까지 항상 동일한 path를 따라 수행한다.

그런데 문제는 바로 이것이다.

  • Stateflow를 Flowchart style로 표현할 수 있다.
  • Flowchart를 Stateflow style로 표현할 수 있다.

위의 문제가 의미하는 것은 Stateflow로 표현하는 것이 더 좋음(어디까지나 주관적인 기준이기는 하지만)에도 불구하고 Flowchart로 표현하는 것이 불가능하지는 않는다는 점이고, Flowchart로 표현하는 것이 더 좋음에도 Stateflow로 표현하는 것이 가능하긴 하다는 점이다.

위에서 기술한 “불가능하지는 않다”의 의미는 이런 뉘앙스이다. 숟가락으로 태국산 쌀로 된 밥을 먹을 수도 있지만, 젓가락으로 그 밥을 먹는다는게 “불가능하지는 않다” 는 의미와 같다. 간단히 말해 비효율적이란 얘기다.

“상태”라는 것은 시스템이 항상 같은 입력에 대해 다른 행동을 하게 되는 경우 “상태”라는 것이 존재한다고 볼 수 있다. 예를 들어 어떤 경우에는 입력A가 들어올 때 행동 A1을 하고 다른 경우에는 입력 A가 들어올 때 행동 A2를 한다고 하면 상태라는 것이 필요한 경우이다. 이 때에는 statechart(or stateflow)로 표현하는 것이 유리하다.

반면, 어떤 경우에도 입력 A가 들어올때 항상 행동 A1을 한다면 그 behavior에 대해서는 굳이 stateflow로 표현할 필요가 없이 flowchart정도로도 가능하다.

flowchart로 표현할 수 있는 것을 stateflow로 표현했을 때는 이해하기가 더 어렵다. 1차원적인 flowchart의  behavior에 대해 n차원의 hierarchy를 가지는 stateflow로 표현할 수 있는데,  hierarchy구조의 diagram을 이해하기 위해서는 뇌에서도 어떤 상태였는지를 기억해야 할 필요가 있다. 즉 특정 상태가 활성화되면 그 상태의 하위 상태의 default transition을 수행해야 하고 그 상태의 하위 상태의.. 이런식으로 hierarchy diagram의 이해가 되기 때문에 확실히 이해하기에는 어려움이 있다.

요약하자면 다음과 같다.

  • stateless인 behavior는 combination table이나 flowchart로 표현하는 것이 더 적합하다.
  • stateful behavior는 stateflow로 표현하는 것이 이해하기 쉬울 수 있다.

 

 

Too many global variables


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, Engineering적인 측면에서 관심있는 것 중에서 하나를 선택해서 글을 쓰고자 한다.

8. Too many global variables

–> 전역변수를 어떻게 관리하느냐에 따라서 소프트웨어의 구조 형태가 많이 달라질 수 있다.

  • 모든 task(혹은 function)이 storage(혹은 pool)에 접근하여 모든 resource에 접근할 수 있는 아키텍처가 있을 수 있다. 가져다 쓰기는 쉽다. 다만 이 경우 전역변수에 의한 dataflow를 면밀히 관리해야 할 필요가 있다. safety시스템에 이런 아키텍처를 사용하는 것이 바람직한지에 대해서 개인적으로는 회의적이다. safety meachnism을 구현해야 하는 관점에서 봤을 때, 구현하기가 만만치 않을 것이기 때문이다. storage의 무결성을 확보해야 하는 것이 필요하고 unintended use/define을 보장해야 하는데,  이것을 구현하는 것이 만만하진 않을 것이다. 모니터링해야 하는 포인트가 너무 많고 이에 대한 오버헤드가 장난 아닐 것이다.
  • 개인적으로 선호하는 스타일인데, component라는 function의 set을 만들고 function에서 사용하는 data들은 component내에 정의하여 component에서만 사용할 수 있도록 한다. component와 component끼리의 data전달은 외부 interface를 통해서 전달할 수 있도록 한다. 이 경우 component내에 정의된 변수가 global변수이냐 아니냐에 대해 argue가 있을 수 있다고 생각하는데, global변수라고 하기에는 reduced scope으로 정의하고 restricted access가 가능하도록 지원하고 관리할 수 있기 때문에 위의 architecture보다는 훨씬 safe하다고 생각한다. monitoring overhead도 보다 적을 것이다.

소프트웨어의 architecture 설계에서 fault tolerant할 수 있도록(or safety mechanism할 수 있도록) 구현한다면, testing관점에서도 그 비용이 feasible한지를 판단할 수 있어야 한다.

아래의 link가 도움이 될 것이다.

http://betterembsw.blogspot.kr/2014/09/fail-safe-mechanisms-must-be-tested.html

 

ISO26262, DO-178C, DO-278A