Telemetrics 개념 공부

---

STM32

STMicroelectronics(이하 ST)에서는 다양한 Cortex-M 마이크로컨트롤러 라인업을 보유하고 있으며 제품명이 STM32로 시작하기 때문에 STM32 시리즈라고도 부른다. STM32 시리즈는 크게 7개의 제품 라인업으로 구성되어 있으며 그 구성은 다음과 같다.

• STM32F7 시리즈: 배정도 부동소숫점 연산자와 DSP를 포함한 최고성능 제품군
• STM32F4 시리즈: 단정도 부동소숫점 연산자와 DSP를 포함한 주력 고성능 제품군
• STM32F3 시리즈: 혼성신호처리 고성능 제품군
• STM32F2 시리즈: 고성능 제품군
• STM32F1 시리즈: 일반 사용제품군
• STM32F0 시리즈: 엔트리 레벨
• STM32L1 시리즈: 초저전력 제품
• STM32W 시리즈: 무선통신용 제품군

ST는 Cortex-M 시리즈를 ARM 사로부터 라이선스 받아 Cortex-M0, Cortex-M3, Cortex-M4, Cortex-M7 제품군 모두를 생산하고 있다. 또한 단순히 칩만 생산하는 것이 아니라 디스커버리 키트나 평가보드도 제공하고 있으며 디버깅 및 프로그래밍을 위한 장비인 ST-Link 등도 판매하고 있다. 그밖에 펌웨어 개발 및 다양한 임베디드 시스템 적용이 용이하도록 주변장치 라이브러리(드라이버)와 DSP 라이브러리, RTOS와 다양한 통신 및 인터페이스 스택을 함께 제공하기 때문에 응용프로그램을 쉽게 개발할 수 있다.

---

MCU

MCU는 Micro ControllerUnit의 약자이다. 마이크로 프로세서와 메모리, 프로그래밍 가능한 입출력 모듈을 하나의 칩으로 만든것이 MCU이다. 프로그래밍을 통해 다양한 제어나 연산작업이 가능하다. 손바닥 컴퓨터인 아두이노는 ATMega328이라는 MCU를 사용한다. MCU의 핵심 블록인 CPU는 연산장치(ALU), 제어장치(CU) 및 레지스터로 구성되어 있다.

MCU의 활용과 프로그래밍 업로드

MCU는 청소기, 냉장고, 가습기, 공기청정기, 세탁기, 정수기, 도어락, TV, 리모콘, 에어컨, 전동 드라이버, 드론, 이어폰, 스마트폰, 자동차 등에 활용된다.전자 장비의 특정한 기능을 구현하려면 MCU에 소스코드로 작성된 프로그램을 MCU가 이해하는 형태로 변환하여 플래시 메모리에 업로드 하는 과정을 거쳐야 한다.MCU는 다양한 입력 센서로부터 신호를 받고, 이를 CPU에서 판단,계산 등의 처리를 하고 결과를 시각,청각 또는 출력 신호로 보낸다.
ex) 시각출력, 청각출력, 입력 신호 센싱, 출력 신호 제어, 통신, 계산 및 처리 등

MCU는 어떻게 프로그래밍 되는가에 따라 다양하게 이용될 수 있다. 프로그래밍 되지 않는 MCU는 쓸모가 없다.
대부분 PC를 통해 MCU 프로그램을 작성한다. 특정한 MCU 프로그래밍이 필요한 애플리케이션은 인터넷에서 다운로드 받을 수 있다.PC에서 프로그래밍이 완료되면 MCU에 프로그램을 넣어야 하는데, 이 작업을 업로드라하며 디버거와 프로그래밍 도구가 필요하다. 아두이노는 이런 도구가 필요 없어서 쉽게 활용할 수 있다는 장점이 있다.

---

UART

UART(범용 비동기화 송수신기: Universal asynchronous receiver/transmitter)는 병렬 데이터의 형태를 직렬 방식으로 전환하여 데이터를 전송하는 컴퓨터 하드웨어의 일종이다. UART는 일반적으로 EIA RS-232, RS-422, RS-485와 같은 통신 표준과 함께 사용한다. UART의 U는 범용을 가리키는데 이는 자료 형태나 전송 속도를 직접 구성할 수 있고 실제 전기 신호 수준과 방식(이를테면 차분 신호)이 일반적으로 UART 바깥의 특정한 드라이버 회로를 통해 관리를 받는다는 뜻이다.

통신 데이터는 메모리 또는 레지스터에 들어 있어 이것을 차례대로 읽어 직렬화 하여 통신한다. 최대 8비트가 기본 단위이다.

UART는 일반적으로 컴퓨터나 주변 기기의 일종으로 병렬 데이터를 직렬화 하여 통신하는 개별 집적 회로이다. 비동기 통신이므로 동기 신호가 전달되지 않는다. 따라서 수신 쪽에서 동기신호를 찾아내어 데이터의 시작과 끝을 시간적으로 알아 처리할 수 있도록 약속되어 있다. 디지털 회로는 자체의 클럭 신호를 추가로 사용하여 정해진 속도로 수신 데이터로부터 비트 구간을 구분하고 그 비트의 논리 상태를 결정하여 데이터 통신을 하는 USRT(범용 동기화 송수신기: Universal synchronous receiver/transmitter)도 사용한다.

UART는 보통 마이크로컨트롤러에도 포함되어 있다. 듀얼 UART, 곧 DUART는 두 개의 UART를 하나의 칩에 합친 것이다. 수많은 현대의 집적 회로(IC)는 동기화 통신인 USRT도 함께 지원한다. 이러한 장치들은 'USARTs'(범용 동기화/비동기화 송수신기: universal synchronous/asynchronous receiver/transmitter) 또는 'USART/UART'로도 부른다.

가장 일반적으로 각 데이터 비트의 시간에 대해 16/64 배 빠른 클럭 신호를 이용하여 시작 비트로부터 세어 각 비트의 경계를 찾아낸다. 이 클럭 신호는 자체적인 내부 클럭 디지털 회로에 의해 발생한다. 보드 설정에 따라 주 클럭으로부터 타이머등을 써서 설정한 속도의 클럭 신호를 만든다. 이것은 프로그래밍에 의한 레지스터 설정에 따라 클럭 신호의 주파수가 바뀐다. 통신 양쪽에서 설정을 미리 약속하고 클럭 신호 발생부의 레지스터를 같은 속도로 설정해야 통신이 원활하게 이루어진다.

아래 예시를 보고 프로젝트에서 사용할때 참고하자.

https://coding-robot.tistory.com/6

[ UART ] 시리얼 통신 , 패킷

---

CAN

CAN(Controller Area Network)이란, 차량 내에서 호스트 컴퓨터 없이 마이크로 컨트롤러나 장치들이 서로 통신하기 위해 설계된 표준 통신 규격입니다. 차량 내 ECU(Electronic control unit)들은 CAN 프로토콜을 사용하여 통신합니다. 초기에는 차량 네트워크용으로 개발되었으나 최근에는 차량뿐만 아니라 산업 전 분야에 폭넓게 적용되고 있으며, 기본적인 시스템 구성은 아래와 같습니다.

 

 

CAN 특징

메시지 지향성 프로토콜(Message-Oriented Protocol)

CAN은 노드의 주소에 의해 데이터가 교환되는 것이 아니라 메시지의 우선순위에 따라 ID(IDentifier)를 할당하고, 이 ID를 이용해 메시지를 구별하는 방식을 사용합니다. 즉, 임의의 한 노드 A가 메시지를 전송했다면, A를 제외한 나머지 노드들은 A가 전송한 메시지가 자신에게 필요한 메시지인지를 판단(ID기반 판단)합니다. 자신에게 필요하다면 받아들이고, 아니라면 무시합니다.

보완적인 에러 감지 메커니즘

CAN은 다양한 에러 감지 메커니즘이 상호 보완적으로 에러를 감지하기 때문에 높은 안정성을 보장합니다. 또한 메시지 전송 시, 에러가 감지되면 자동적으로 해당 메시지를 즉시 재전송하는 기능이 있기 때문에 다른 프로토콜에 비해 에러 회복 시간이 짧습니다.

멀티 마스터 능력

CAN을 기반으로 한 네트워크에는 버스를 점유하기 위한 감독자 노드(Bus Master)의 필요가 없습니다. 즉 모든 노드가 버스 마스터가 되어 버스가 비어 있을 때(idle)라면 언제든지 메시지 전송이 가능합니다. 모든 노드는 버스가 비워지는 즉시 메시지 전송을 시작합니다. 만약 CAN 버스에서 두 개의 노드에서 메시지를 동시에 전송하려고 하더라도, 우선순위(식별자, ID)에 따라 각각 전송이 됩니다. 즉 우선순위가 높은 메시지(이 때, 더 낮은 ID 번호가 더 높은 우선순위를 가짐)가 먼저 전송이 됩니다.

결점 있는 노드의 감지와 비활성화

CAN은 버스의 상태를 항상 모니터링하기 때문에 실시간으로 결함이 있는 노드를 감지해 해당 노드를 비활성화함으로써 네트워크의 신뢰성을 보장합니다.

전기적 노이즈에 강함

꼬인 2선(Twist Pair Wire, *CAN_H, CAN_L)을 이용하여 전기적으로 차별되는 통신을 하여 전기적 노이즈에 매우 강합니다.

저렴한 가격 및 구성의 용이성

현재 수십 개의 반도체 제조업체가 다양한 CAN 컨트롤러와 트랜시버를 개발 및 판매하고 있어 가격이 저렴하고 조달이 용이합니다.

CAN 등장 배경

초기에는 자동차 안에 모듈이 많지 않았기 때문에 UART방식, 즉 일대일(Point-To-Point) 방식으로 ECU를 연결했습니다. 하지만 이런 방식이라면 서로 다른 모듈간 통신을 위해서는 많은 선(line)이 필요한 것이 문제가 됩니다. 이는 배선의 증가로 인한 유지 보수 문제, 그리고 배선 증가로 인한 무게 증가, 연비 하락과도 연결이 되었으며 기술의 발전으로 차량 내부에 모듈 수가 점점 증가하고 있는 만큼 이와 같은 문제의 해결이 필요했습니다. 이러한 문제를 해결한 것이 바로 CAN입니다.

CAN BUS 네트워크 동작원리

CAN은 다중통신망(Multi Master Network)이며 CSMA/CD+AMP(Carrier Sense Multiple Access/Collision Detection with Arbitration on Message Priority) 방식을 이용합니다. 먼저 CAN 노드에 메시지를 보내기 전에 CAN 버스라인이 사용 중인지를 파악합니다. 또한 메시지 간 충돌 검출을 수행합니다. 이 때 어떠한 노드로부터 보내진 메시지는 송신측이나 수신측의 주소를 포함하지 않습니다. 즉 주소지정방식으로 통신하지 않습니다. 대신 메시지의 처음부분에 CAN 네트워크상에서 각각의 노드를 식별할 수 있도록 각 노드마다 유일한 식별자(ID-11bits 또는 29bits)를 가지고 있습니다.

CAN 메시지 포맷(구조)

CAN에서는 데이터 프레임(data frame), 리모트 프레임(remote frame), 에러 프레임(error frame), 오버로드 프레임(overload frame)의 4가지 프레임 타입을 정의하고 있습니다. 데이터 프레임은 일반적으로 데이터 전송에 사용되며, 리모트 프레임은 수신할 노드에서 원하는 메시지를 전송할 수 있는 송신 노드에게 전송을 요청할 때 사용됩니다. 에러 프레임은 메시지의 에러가 감지되었을 때 시스템에 알릴 목적으로 사용됩니다. 마지막으로 오버로드 프레임은 메시지의 동기화를 목적으로 사용됩니다. CAN 통신에서 데이터 송수신은 메시지 프레임을 사용하여 이루어집니다. 메시지 프레임의 구조는 다음과 같습니다.

---

InfluxDB

Influx DB란 많은 쓰기 작업과 쿼리 부하를 처리하기 위해 2013년에 Go 언어로 개발된 오픈소스 Time Series Database(시계열 데이터베이스)로써 Tick Stack(Telegraf + InfluxDB + Chronograf + Kapacitor)의 필수 컴포넌트 중 하나이다. Influx DB는 많은 TSDB들(Prometheus, TimescaleDB, Graphite, 등) 중에서 가장 유명하고, 많이 사용되는 데이터베이스이다. Influx DB는 Distributed, Scale horizontally하게 설계되어 새로운 노드만 추가하면 손쉽게 scale-out할 수 있으며, Restful API를 제공하고 있어 API 통신이 가능하다.

 

• 많은 쓰기 작업과 쿼리 부하를 처리하기 위해 2013년에 Go 언어로 개발된 오픈소스 TSDB
• Tick Stack의 필수 컴포넌트 중 하나
• 가장 유명하고, 많이 사용되는 TSDB
• Distributed, Scale horizontally하게 설계되어 scale-out이 쉬우며, Restful API를 제공하고 있어 API 통신이 가능 

TICK Stack이란 InfluxData에서 나온 4가지 오픈소스 컴포넌트들을 기반으로 구축한 시스템이다. 4가지 컴포넌트들은 조합되어 모니터링할 데이터를 수집하여 저장하고, 알림을 보낸다.

• Telegraf: Metrics와 Events를 수집하고 리포팅하는 모듈
• InfluxDB: Time Series DB(시계열 데이터베이스)
• Kapacitor: Real-time 스트리밍 데이터 전송 엔진
• Chronograf: 시각화 도구

 

InfluxDB는 2가지 핵심 기능을 제공하고 있는데, 그것은 바로 일정 주기마다 데이터를 처리하여 새롭게 저장하는 기능과 일정 주기마다 데이터를 자동으로 삭제하는 기능이다.

위의 2가지 핵심 기능은 대량으로 쌓이는 시계열 데이터를 보다 편리하게 처리할 수 있도록 제공하고 있다.

 

Continous Query(연속적인 쿼리), Task

Influx DB의 핵심 목적은 시간에 따른 데이터(시계열 데이터)의 처리이다. InfluxDB는 데이터를 처리하여 새롭게 저장하는 Down Sampling(다운 샘플링)을 일정 주기마다 실행되도록 하는 Continous Query(연속적인 쿼리)를 제공하고 있다.

InfluxDB2에서는 Continous Query를 대체하는 Task를 제공하고 있다.

 

Retention Policy(보존 정책), Retention Period

Influx DB의 핵심 목적은 시간에 따른 데이터의 삽입과 조회이므로 직접 Delete를 이용하는 경우는 거의 없다. 하지만 데이터가 계속해서 쌓이면 저장 공간 및 처리 속도 등에 문제가 생기므로 데이터를 자동으로 삭제해주는 Retention Policy(보존 정책)를 지원하고 있다.

Retention Policy란 오래된 데이터를 자동으로 삭제해주는 정책으로써 데이터베이스 단위로 정의되며 일반적으로 1개의 데이터베이스는 여러 개의 보존 정책을 가지고 있다.

만약 별도의 설정을 하지 않았다면 autogen이라는 기본 정책으로 적용된다. autogen은 보존 기간이 무제한이므로, 별도의 설정을 해주지 않으면 데이터가 계속해서 쌓이고 문제를 일으키게 된다. 그러므로 별도의 설정을 해줌으로써 오래된 데이터들을 관리하는 작업이 필요하다.

InfluxDB2에서는 Retention Policy를 대체하는 Retention Period를 제공하고 있다.

 

RDB VS InfluxDB 구조

 

 

시계열 데이터베이스에서 측정의 의미를 가지는 measurement는 관계형 데이터베이스의 table에 해당하며, RDB와 마찬가지로 하나의 데이터베이스 안에 여러 개의 measurement가 있을 수 있다. 이를 그림으로 표현하면 다음과 같다.

 

하지만 RDB와 차별화된 핵심 컨셉이 있는데, InfluxDB는 NoSQL의 개념을 바탕으로 만들어져서 RDB와 다르게 Schemaless(스키마가 없음) 하다는 점이다.

기존의 RDB로 개발을 할 때에는 필요한 컬럼들과 길이 및 타입 등을 설계하면서 테이블의 스키마를 구성해주어야 했다. 하지만 InfluxDB는 Schemaless 데이터베이스이므로, 새로운 데이터를 추가하는 시점에 Measurement와 관련 컬럼들이 추가되며 이러한 이유로 스키마의 변경이 매우 빠르다. InfluxDB는 이러한 구조를 가져감으로써 시계열 데이터에 유연하게 대처할 수 있도록 하였다.

---