Embedded system이 복잡해지고 interconnected되면서 다양한 산업에 사용되게 된다. 그러다 보니 새로운 개념이 되었고, 이를 Cyber-Physical Systems (CPS)라 부르게 된다.

 

1. CPS란 무엇인가?

Cyber/computational components에 의해 controll되고 integrated되는 physical system을 말한다. 이러한 시스템은 physical system의 실시간 데이터를 기반으로 의사결정을 내리며, 자율주행 차량, 스마트 그리드 등 다양한 분야에 활용된다.

 

기존의 embedded system과의 가장 큰 차이는 다음과 같다. 기존에는 서브 시스템 간의 black box 관계를 가졌던 것과 다르게 CPS는 서로 open protocol로 연결되어 있어 white box라는 점이다. 

 

2. CPS 요구사항

  • Safety : System failure는 큰 문제를 발생함. System correctness는 각 서브시스템의 logical result와 제시간에 결과가 나와야 하는 것에 결정됨.
  • Performance : Safety가 제1순위로 중요하며, 그 다음은 performance임. 대부분의 시스템의 자원은 제한적이기 때문.
  • Interoperability : 각 서브시스템은 open protocol에 의해 통신됨. 보안이 문제가 될 수 있음.

 

이를 위해 컴퓨터 구조, CAD, 시스템 디자인, 소프트웨어 공학, domain knowledge 등을 고려해야 하며, 이는 복잡하기 때문에 기존과는 디자인 방법이 제안된다.

 

3. CPS design

Stack-based design, ECE

시스템을 디자인하는 데 있어 가장 큰 챌린지는 abstraction을 어떻게 할지 였다. 보통의 경우 stack-based design을 제안하지만 Concurrency, Criticality, Timing(Deadline)에 대한 고려가 부족했다. 그림은 2011년에 ISORC에 제안된 구조로 각 layer 별로 requirement를 충족하는지 확인하고 만족하지 못하면 redesign을 수행하며 layer에서 처리가 불가능하면 상위 layer에서 지원하도록 디자인했다.

 

현재는 다음의 design flow를 가지고 있다.

Current design

우선 구현을 진행하고 analysis를 통해 안전성, 성능 등을 평가하게 된다. 구현보다는 Analysis에 많은 시간과 비용이 소모되며 안전성 문제가 직결된 만큼 매우 어려운 과정이다.

 

Analysis가 잘못되면 다음의 문제가 생기기도 한다. 2007년 12월 F-22s 전투기는 하와이에서 일본으로 비행중이었는데, IDL을 넘어가자 12가지의 서브시스템이 crashed되어 다운되었다. 시간 테이블이 변경되면서 기체 이상이 발생하였던 것이다.

 

4. CPS challenges - Safety

Security issue와 Fault tolerance, Lower-criticality subsystems의 오작동 문제가 있다.

  • Security issue : open protocol 사용에 의한, 혹은 jaming에 의한 문제
  • Fault tolerance : user의 실수로부터 시스템을 보호하는 문제
  • Lower-criticality subsystems : 낮은 중요도의 서브시스템 오작동으로 인한 고위험도 서브시스템의 오작동 문제

 

이를 해결하기 위해서 Formal verification이나 certification을 생각해 볼 수 있다.

  • Formal verification : modelling을 잘해서 모든 input에 대한 output을 확인할 수 있다면, 안전성을 보장할 수 있다. 그러나 complexity 문제, 구현 문제 등의 어려움이 있다.
  • Certification : 표준에 의한 인증을 수행하는 방법이다.

 

5. CPS challenges - Integration

서브시스템을 구현하는 것은 오래 걸리지 않지만, 디버깅하고 verification하는 데 많은 시간과 비용, 노력이 소모되는 문제가 있다. CPS 디자인 프로세스가 발전될 필요가 있음을 시사하는 파트이다.

 

6. CPS challenges - Timing predictability

가장 challeng한 문제이다. 일반적으로 lower layer는 hardware의 특성상 시간 소모가 deterministic하게 나온다. 문제는 higher layer의 timing으로 layer를 지나면서 HW의 timing 정보가 손실되다 보니 문제가 발생하게 된다. General purpose PC라면 상관 없을 수 있겠지만, 임베디드 시스템에서 deadline을 맞추는 것은 중요하다 보니 unpredictable하면 안된다.

 

일정 시간을 보장해줘야 하기 때문에, worst-case performance를 가정하여 timing predictability를 결정하게 된다.

 

7. CPS challenges - System correctness

  • Logical correctness : 시스템이 올바른 결과물을 생성함.
  • Temporal correctness : 시스템이 결과물을 올바른 시간에 생성함.

 

Timing analysis가 중요하며, 이를 위해 isolated한 분석(서브시스템 별로 independent 검증)을 수행한다. 보통 문제가 발생하는 경우는 HW와 SW 자원이 여러 서브시스템에 의해 공유되는 상황이다.

 

이를 해결하기 위해서는 Isolation이 필요하다. Memory garbage와 trade-off 관계가 있다. 현재 구조는 logical isolation에 치중되어 있기 때문에 memory 보호나 privilege level의 문제가 발생할 수 있다. 그렇다고 temporal isolation하자니 성능이 너무 안좋아지는 경향이 있다.

 

8. CPS challenges - Software models

보통 C로 구현하게 되는데, C에는 concurrency나 timing parameters, synchronization, deadline을 위한 기능이 없다. CPS 구현에 어려움이 있을 수 있다.

 

9. CPS challengs - Security

시스템이 interconnected되면서 공격 받을 수 있는 point가 많아졌다. 최근의 사례로는 Stuxnet이 있다.