길리랩blog

TinyOS 내부 구조 — nesC 정적 배선이 만드는 초저전력

TinyOS의 nesC 컴포넌트·인터페이스 배선, 이벤트/태스크 동시성 모델, 전력 관리 구조를 Contiki-NG·RIOT·FreeRTOS와 비교하고 nesC 코드 예제로 정리한다.

2026-08-13 · 최초 발행 2025-12-05

배터리 하나로 5년을 버텨야 하는 센서 노드에 범용 OS를 올릴 수는 없다. TinyOS는 초소형 노드용 이벤트 기반 운영체제이자 프레임워크로, 정적 컴포넌트(모듈·인터페이스) 결합과 비차단 I/O, 태스크 기반 협력적 스케줄링을 핵심으로 한다. nesC 언어 기반이며 command/event 인터페이스와 split-phase I/O로 지연이 큰 작업을 이벤트로 분리하고 태스크는 FIFO로 지연 실행한다 — 인터럽트는 태스크를 선점할 수 있지만 태스크 간 선점은 없다. 802.15.4 등 저전력 무선, 센싱·로깅, 장기 배터리 구동 노드가 주 타깃이고, TOSSIM 시뮬레이터와 telosb·micaz 같은 실제 보드에 동일 코드를 배포할 수 있다(활성 개발 범위와 최신 보드 지원 여부는 별도 확인 필요).

컴포넌트가 정적으로 배선되는 이유

모듈은 제공(provides)·사용(uses) 인터페이스를 정의하고, 구성(configuration)에서 정적으로 배선한다. 런타임 의존성 해소 비용이 사라지고 인터페이스 수준에서 병행성이 규율된다. command는 동기 요청, event는 비동기 콜백으로 구분돼 코드 경로와 자원 사용이 컴파일 시점에 명확해진다.

이벤트에서 태스크로 이어지는 동시성 모델

인터럽트→이벤트→태스크 순으로 처리 흐름이 구성된다. 태스크는 짧고 비선점적으로 실행되며 공용 자원에 접근할 때는 atomic 구문으로 임계 영역을 보호한다. split-phase I/O로 장시간 블록을 회피하고, 라디오·센싱 연산을 비동기화해 응답성과 전력 효율을 극대화한다.

전력 관리와 무선 스택

라디오 듀티사이클링, 센서·MCU 슬립 모드 제어, 타이머 구동 최소화로 에너지 예산 중심 설계가 쉬워진다. Active Message(AM) 추상화, CSMA/ACK/재전송, CC2420 같은 링크 계층 드라이버와 라우팅 컴포넌트를 제공한다.

툴체인과 시뮬레이션

nesC 컴파일러(ncc)와 make 기반 멀티플랫폼 빌드를 쓰며, 동일 소스를 시뮬레이션(TOSSIM)과 실기기에서 모두 실행할 수 있다. 대규모 토폴로지 테스트, 패킷 레벨 디버깅, 에너지 정책 가정 검증을 지원한다.

메모리와 신뢰성

정적 메모리 배치를 중심으로 하고 힙 할당을 최소화하거나 배제하는 구성이 가능하다. 푸트프린트는 수 kB~수십 kB 수준이다. 인터페이스 계약과 정적 배선으로 데이터 경합·스택 사용량의 예측성이 높아지고, 하드웨어 의존부(HAL)를 분리해 이식성을 확보한다.

패킷 하나가 나가는 경로

⤢✕busy = truebusy = false필요불필요성공실패시간 이벤트 'fired' 수신'prepare' 태스크 post태스크 'prepare' 실행:페이로드 작성AMSend 'busy' 여부 확인큐 보유 또는 드롭(정책)AMSend 호출 및 'sendDone'대기ACK 필요 여부MAC 재시도 N회 및 백오프전송 완료 처리에러 로깅 및 지표 증가메트릭 기록(드롭/지연)저전력 진입(라디오/MCU 슬립)

입력은 타이머 이벤트, 센서 데이터, 송신 요구다. 처리는 태스크 준비 → AMSend 호출 → ACK/재시도 정책 적용 → 메트릭 기록 순이고, 출력은 전송 완료 또는 실패 로깅과 전력 절약 모드 진입이다. busy 충돌 시에는 큐잉·드롭 정책으로, 재시도 한계 초과 시에는 오류 누적으로 처리한다.

환경 모니터링·예지보전·프로토콜 실험에서의 자리

환경 모니터링(산림·농업·건물)은 초저주기 센싱과 라디오 듀티사이클링으로 수년 단위 수명을 설계하고 메쉬 라우팅으로 넓은 커버리지를 구성한다. 절차는 센싱 입력 → 임계치 필터링 → 버퍼·배치 → 저전력 송신 → 게이트웨이 수집이다.

설비 상태 진단·예지보전은 진동·온도 이벤트 기반으로 임계치 초과 시만 전송해 배터리 소모를 최소화하며, 현장 펌웨어 무선 업데이트는 제한적이라 물리적 접근이나 게이트웨이 보조가 필요하다. 절차는 센싱 입력 → 특징 추출 → 이벤트 발생 시 송신 → 알람·대시보드다.

교육·연구·프로토콜 실험은 TOSSIM으로 대규모 토폴로지·파라미터 스윕을 돌리고 MAC·라우팅 구성요소를 교체 시험한다. 절차는 지표 정의 → 시뮬레이션 → 파라미터 튜닝 → 실장 배포다.

TinyOS와 다른 RTOS 비교

구분 TinyOS Contiki-NG RIOT FreeRTOS
동시성 모델 이벤트/태스크, 비선점 태스크, 인터럽트 선점 이벤트 기반 + 프로토스레드(경량 협력) 스레드 기반(프리엠프티브), 이벤트 큐 지원 스레드 기반(프리엠프티브), RT 커널
메모리/풋프린트 kB~수십 kB, 정적 배선 중심 소형, 동적 기능 유연 중소형, 모듈성 높음 커널 소형, 기능 추가에 따라 증가
전력관리 강점, 듀티사이클 정교 강점, ContikiMAC 등 보통, 정책 구성 용이 정책 구현 필요, 하드웨어 의존
네트워킹 스택 AM, 802.15.4 중심 6LoWPAN/IPv6 강점 6LoWPAN/IPv6, 다수 드라이버 TCP/IP는 외부 스택 통합
개발 편의 nesC 학습 곡선, TOSSIM 우수 C 기반, 문서 풍부 POSIX 유사 API 편의 광범위 예제, 친숙한 RTOS
실시간성 소프트 실시간, 태스크 비선점 소프트 실시간 소프트~하드 실시간 구성 가능 하드 실시간 패턴 용이

선택 기준은 뚜렷하다. 초저전력·정적 예측성이 최우선이면 TinyOS, IP 네트워킹·상호운용이 중심이면 Contiki-NG·RIOT, 스레드 기반 제어와 RT 요구가 크면 FreeRTOS가 적합하다.

배터리는 실제로 얼마나 가는가

전력 효율은 이벤트 기반·듀티사이클링으로 평균 전류를 수십 µA 수준까지 설계할 수 있다는 데서 나온다. 수명 계산 예시로 평균 전류 50 µA, 배터리 2400 mAh(= 2400 mA·h)를 가정하면 수명(h) = 2400 mA·h / 0.05 mA = 48,000 h ≈ 5.48년이 나온다. 다만 셀프방전·온도·피크전류로 실제 수명은 30~50% 단축될 수 있다. 신뢰성·예측성 측면에서는 정적 배선과 인터페이스 계약이 경합·스택 오버런 리스크를 줄이고, 운용 비용 절감 측면에서는 현장 방문 주기가 늘고 네트워크 유지보수가 단순해진다.

보안·운영에서 놓치기 쉬운 것

링크 계층 암호화는 802.15.4 AES-CCM 하드웨어를 우선 사용하며, 키 관리 단순화와 재키잉 비용 증가는 트레이드오프 관계다(최신 취약점·칩셋 펌웨어 상태는 별도 확인 필요). 무선 재시도 정책은 재시도 횟수를 늘리면 신뢰성이 오르는 대신 전력 소모도 늘어나므로, 환경 RSSI·간섭 측정 기반의 적응형 백오프를 적용하는 편이 낫다. 동시성 안전을 위해서는 공유 버퍼 접근에 atomic을 쓰고 이벤트 안에서 장시간 연산을 금지해야 하며, 라디오 드라이버의 busy 충돌 시에는 큐잉 정책과 드롭 메트릭이 필수다. 관측 가능성 확보를 위해 전송 실패율, 큐 길이, 남은 배터리 추정치를 노출하고, TOSSIM 단계에서 목표 KPI 달성을 검증한 뒤 현장에 배포한다.

nesC로 짜보는 주기 센싱·브로드캐스트

전제는 Ubuntu 20.04, TinyOS 2.1.2, 플랫폼 telosb다. 빌드는 프로젝트 루트에서 make telosb로 실행한다.

BlinkSendC.nc (Module)

#include "tos.h"
#include "AM.h"
#include "Timer.h"
#include "message.h"

module BlinkSendC {
  uses interface Boot;
  uses interface Timer<TMilli> as Timer0;
  uses interface AMSend as RadioSend;
  uses interface Packet;
}
implementation {
  message_t pkt;
  bool busy = FALSE;
  uint16_t seq = 0;

  event void Boot.booted() {
    call Timer0.startPeriodic(1000);
  }

  event void Timer0.fired() {
    post prepare();
  }

  task void prepare() {
    if (busy) return; // 드롭 정책
    uint8_t* p = call Packet.getPayload(&pkt, sizeof(uint16_t));
    if (p == NULL) return;
    *((uint16_t*)p) = seq++;
    if (call RadioSend.send(AM_BROADCAST_ADDR, &pkt, sizeof(uint16_t)) == SUCCESS) {
      busy = TRUE;
    }
  }

  event void RadioSend.sendDone(message_t* m, error_t err) {
    busy = FALSE;
    // 필요 시 ACK/에러 처리
  }
}

BlinkSendAppC.nc (Configuration)

configuration BlinkSendAppC { }
implementation {
  components MainC, BlinkSendC as App;
  components new TimerMilliC() as T0;
  components ActiveMessageC;
  components new AMSenderC(6) as Sender; // AM 타입 6 예시

  App.Boot -> MainC.Boot;
  App.Timer0 -> T0;
  App.RadioSend -> Sender;
  App.Packet -> Sender;
}

핵심은 타이머 이벤트에서 태스크로 작업을 이관하고, busy 충돌 시 드롭하며, sendDone에서 busy를 해제하는 흐름이다. 실환경에서는 큐잉·재시도·메트릭을 추가해야 한다.

어떤 프로젝트에 맞나

TinyOS는 이벤트 기반 모델과 정적 컴포넌트 구조로 초저전력·예측성·신뢰성을 중시하는 센서 네트워크에 적합한 운영체제다. 학습 곡선과 특화된 언어라는 진입장벽이 있지만, 전력 예산·메모리 제약이 엄격한 프로젝트에서는 그만큼 효용이 크다. 프로토콜·전력 정책을 시뮬레이션으로 먼저 검증한 뒤 단계적으로 현장에 배포하는 방식을 권장한다.

TinyOSnesC임베디드 OS센서 네트워크저전력 설계