design interview prep

[hyunsik-yoon]

https://www.geeksforgeeks.org/system-design-tutorial/?ref=rightbarsticky

TODO

• [x] microservice architecture in embedded system

[hyunsik-yoon]

SOLID

(https://en.wikipedia.org/wiki/SOLID)

• The Single-responsibility principle: "There should never be more than one reason for a class to change."[5] In other words, every class should have only one responsibility.[6]
• The Open–closed principle: "Software entities ... should be open for extension, but closed for modification."[7]
  • A module will be said to be open if it is still available for extension.
  • The existing interface is closed to modifications and new implementations must, at a minimum, implement that interface.
• The Liskov substitution principle: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."[8] See also design by contract.[8]
• The Interface segregation principle: "Clients should not be forced to depend upon interfaces that they do not use."[9][4]
• The Dependency inversion principle: "Depend upon abstractions, [not] concretions."[10][4]
  • High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
  • Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

YAGNI

You Ain't Gonna Need It, a principle that encourages developers to avoid implementing features or functionality until they are actually needed.

[hyunsik-yoon]

https://www.embedded.com/5-steps-to-designing-an-embedded-software-architecture-step-1/

in Embedded architecture,

1st step: Separate the software architecture

• HW layer를 잘 추상화하고 그 위에 SW layer를 만든다. (HAL)
  • application은 HW를 몰라야 함
  • why?
  • HW 자체가 바뀔 수 있다.
  • test 가 쉽다. (SW는 SW 만 따로 테스트 가능)
  • HW와 SW가 tightly couple 되면 scalability 문제가 있다. 서로간에 data 공유하는 일이 많고, 점점 새로운 기능을 넣기가 힘들어진다.
  • application은 HW가 준비되기 전에 개발 시작될 수 있음

2nd step: Identify and trace data assets

• The first principle for modern embedded software design is “Data Dictates Design.”
• input data, output data, data to process 들을 규명한다.
  • data flow diagram

3rd step: Decompose the system

• decomposition is the act of taking our data assets and creating the building blocks of the software architecture, like the software tasks, threads, and other organizational mechanisms.

Decomposing by Security

• secure 에서 처리되는 것과 non secure에서 처리되는 것을 구
• secure 한 것들 처리 방법 예시
  • these data assets will likely need to be placed in a hardware-isolated execution environment.
  • these data assets might require additional memory protection units (MPUs) to be configured to limit access.
  • there may even be Root-of-Trust services that need to be implemented to manage the data assets and access them.

Decomposing by Domain

• input, output, motor control 등과 같이 domain을 구분해본다.
• 각각 domain간은 msg queue 같은 것으로 communication

Decomposing by Task (link)

• A task is a logical grouping of source code and architectural ideas that are related to each other and solve a software problem.
• each task has a single responsibility
  • For example, if the customer requires diagnostics in the near future, we can add a diagnostic task.
  • If more sensors are added, the sensor task can manage them.
• Next, we should decompose some initial communication architectures
  • data flow를 그렸으므로 각각에 맞는 방법을 찾는데
  • ex) sensor task -> controller task : msg queue

4th step: Interface and component design (link)

• motor task 는 예를 들어, 아래처럼 쪼갠다

  

• 그담에 상세화

  • MotorTask 가 아래의 class들을 써서 motor를 제어하는 구조
  • 아래의 아이들은 모두 한 task에서 동작하는 듯 (글의 표현상 MotorQ를 정의해서 task로 정보를 보낸다고 되어 있고, task는 motor driver를 call한다고 되어 있다)
  • 

5th step: simulate, iterate, scale

• 좋은 아키텍쳐는 변경 반영이 용이하고, 미래에 확장( scalability 라는 표현을 쓰더라 )이 가능해야 한다.

[hyunsik-yoon]

Microservices in Embedded Linux

• from here
• middleware 를 fine-grained 서비스들로 구성
• 장점
  • service 개별적으로 구현가능
  • 서로 loosely coupled
  • 개별적 deploy 가능
  • debugging과 테스트 쉬움
• Linux 구현 사례
  • Daemon (== service)
  • several threads
  • socket 통해 통신
    • fd = socket(AF_UNIX, SOCK_DGRAM, 0)
    • msg: binary C structure
  • status 저장(shared memory)
    • id = shmget(key, size, flag)
    • 쓰는 애는 write mode, 나머지 daemon들은 read mode
    • binary C structure
  • logging
    • changed from syslog to own logger
    • 참고. syslog는 centralized logging system로 /var/log/syslog 등에 로그 저장

      openlog("myapp", LOG_CONS | LOG_PID, LOG_USER);
      syslog(LOG_INFO, "Hello, world!");
      closelog();

  • xmld (XML -> internal format)
  • bootd
  • powerd (power supply peripheral)
  • muxd
  • 여러 sensor 들 data를 읽어서 적당한 곳에 보낸
  • cmdd (internal data -> sensor specific data 로 변경하여 센서 제어)
  • dumpd
  • daemon의 current status 를 보여주기
  • launchd
  • daemon을 띄워주는 역할. daemon이 죽으면 다시 띄워주기도 함.
  • CPU, mem 을 모니터 (daemon 이 이상하면 죽이기도 하고)
• 설계 철학 사례
  • 한 daemon이 죽어도 다른 daemon이 영향받으면 안된다.
  • 다른 daemon의 존재에 영향받지 않아야 한다.
• FreeRTOS 구현 사례
  • no process, only tasks
  • not restartable (하나가 죽으면 모두 죽는다)
  • comunication task
  • UART communication
  • motor task
  • position task (depth sensor, accellation sencor 에서 position 읽음)
  • steering task
  • position task 에서 정보를 받고 motor task 를 제어
  • message queue 사용하여 통신 (send queue, receive queue 두개)
• 고려점
  • task 가 많으면 memory와 CPU를 를 많이 쓰게 될 수 있다.
  • communication이 많아진다. 이게 속도를 느리게 할 수도.
  • malicious code의 공격가능 포인트도 많아진다.