센서 투명성을 지원하는 센서노드 OS

1. 센서 투명성을 지원하는 센서노드 OS 2008. 3. 31. 은 성 배, 한남대학교 ㈜옥타컴, 부설연구소

2. 차 례 • USN 응용 개발의 어려움 • 센서의 다양성 • USN 응용 개발의 현황 • 센서 투명성 지원 기술현황 • 기존 센서노드 OS의 한계 • IEEE1451의 한계 • 센서 디바이스 관리 시스템 • 센서 디바이스 추상화 • 응용 프로그램 API • 센서 HAL • 센서 디바이스 프로그래밍 • 디바이스 드라이버 개발 사례 • 응용 개발 사례 • 향후 연구 과제 • 플랫폼 구조 • DD 원격 다운로딩 • DD 분산 관리 시스템

3. 1. USN 응용 개발의 어려움

4. USN에는 센서가 없다!!! 붕어빵에는 붕어가 없다!!!

5. 센서의 특징 • USN 응용 개발 • USN 응용 개발 과정 • 센서 선정이 첫번째 과정 • MCU, RF, 전력부 등은 • 기 개발된 플랫폼을 사용 • 센서부품들을 연결, 조립, 플랫폼과 연결 • 그 위에서 응용 개발 • 센서의 다양성 • 다종: 온도, 조도, 습도 등 • 운영환경: 일반 대기온도, 수온, 매우 높은 온도, 비접촉식 등 • 물리적 인터페이스의 다양성 • ADC 연결, 디지털 직접 입력, 주파수 방식, • 인터럽트, 직렬 연결, I2C, SPI 등

6. 센서의 복잡성[1] • 센서의 다양성

7. 센서의 복잡성[2] • 센서의 비선형성

8. 센서의 복잡성[3] • 4-D 데이터 처리 • 3차원 위치 정보 + 시간 정보 • 예1) 시간 축: 서로 다른 시간대 센서 값 상이 • 예2) 공간 축: 같은 시간이라도 장소에 따라 다른 값 • GIS와의 연동 • 기존 3차원 GIS의 수정 보완 등

9. 센서 노드 구현시 문제점 • 센서노드와 센서의 분리 • 대부분의 환경 모니터링 응용 • 센서노드는 환경과 분리 • 방수, 방진 등 • 센서는 환경속에서 동작되어야 함 • 수질 센서, 대기 센서 등. • 동작전압의 차이 • 동작 전압이 낮을 수록 저전력에 유리 • MCU는 3~2.7V 동작 • 센서는 3V, 5V, 9V, 12V로 매우 다양 • 센서 수명이 짧음 • 환경속에서 동작한다는 특성상 • 노드 수명보다 센서 수명이 짧음 • 주기적으로 교체 가능해야 함

10. USN 응용 개발의 현황[1] • 현재의 응용 개발 모습 • USN 솔루션업체가 고군분투 • 응용 개발도 어렵고 • 규모의 경제 실현도 어려움 자체 F/W개발 Tiny OS 활용 Nano-Q+활용 솔루션개발 응용개발요구 S/W 개발 H/W 조립 Sensor n MCU k RF l … … … Sensor 0 MCU 0 RF 0

11. USN 응용 개발의 현황[2] • 사례 1 • 특정(예: 가속도) 센싱 데이터를 802.15.4로 중앙에 전송하는 응용 => Tiny-OS /ATmega128 플랫폼 기준 • HW: 가속도 센서를 위한 HW 모듈 개발 및 연결 • 플랫폼의 빈 포트 확인 및 센서 연결 • SW: 타이머 관련 OS 라이브러리 사용 주기적으로 센싱하여 통신 라이브러리 로 중앙에 전송 • 포트 초기화 및 설정 • 특정 주기로 타이머 인터럽트 설정 • 그 포트 값을 읽을 때 적절한 시간 지연 설정 • 통신라이브러리를 활용 전송 • 슬립 시, 포트 전원 off 및 OS의 슬립 라이브러리 호출 => 센서+ATmega128+Tiny-OS 모두를 잘 알아야 함.

12. USN 응용 개발의 현황[3] • 사례 2 • 모 SI 업체가 수질관련 센서노드 개발 요구 • 매우 간단한 작업이었으나 • 1주일 개발, 500만원 => USN 응용 확산에 걸림돌

13. 응용 개발자 센서 응용 표준화된 API 기반 플랫폼 공급자 센서 디바이스 공급자 저가격/고성능SN 플랫폼 Sensor 및 디바이스 드라이버 센서노드 플랫폼 기반 응용 개발[1] • 센서노드 플랫폼 기반 응용 개발 • 3 주체가 자신의 역할에 최선을 다함 • 응용 개발이 용이해짐 • 규모의 경제 실현하여 저가격 실현 • USN 개발 활성화에 기여 B B

14. 센서노드 플랫폼 기반 응용 개발[2] • 플랫폼 공급자 • MCU + OS + 전원 + 센서인터페이스 • 다양한 시장 요구를 수용 => 최적화된 플랫폼 제공 • 예) 저전력소모형 플랫폼: MSP430 + cc2420 • 적절한 전원 및 센서인터페이스 제공 • ADC + 전압 인터페이스, ADC + 미세전압 인터페이스 등 • Uniform한 OS 인터페이스 제공 • 센서모듈 개발자 • 센서 + 디바이스 드라이버 • 응용 개발자 • 센서 사용자 매뉴얼 + 센서노드 플랫폼을 활용 • Linux위에서 응용 개발하듯이 프로그램 작성

15. 2. 센서 투명성 지원 기술현황

16. USN 응용 Application Application Programming Interface(API) ThreadMgmt. MemoryMgmt. TimeMgmt. Device Driver Interface Device Driver O.S. 센서노드 플랫폼 Hardware Abstraction Layer(HAL) MCU RF Power Sensor Interface Sensor H.W. 센서 노드 OS[1] • 개념적인 구조도 • 센서 HW를 Encapsulation해야 함 • API가 센서 접근을 추상화해야 함 • 센서 다양성 => 기존 OS 지원 없음

17. USN 응용 Application Sensor HW 및 드라이버 직접 제작 Application Programming Interface(API) ThreadMgmt. MemoryMgmt. TimeMgmt. Device Driver Interface O.S. Hardware Abstraction Layer(HAL) MCU RF Power Sensor Interface H.W. 센서 노드 OS[2] • 기존 운영체제의 한계 • Tiny-OS • 이벤트 기반 멀티태스킹 • NesC 프로그램밍 언어 • 센서의 다양성과 복잡성을 고려한 특징 없음 • SOS • 다중 모듈 동적 로딩 • 디바이스 드라이버 관리 기술 없음 • MANTIS • 레이어 기반 운영체제 • 하드웨어를 추상화시키는 디바이스 특징 • 디바이스 순서 고정된 단점 • Nano-Q+ • 저전력 슬립모드 • 멀티 스레드 간의 스택 공유 • 멀티 스레드 스케줄러 방식 • 센서 디바이스 추상화 지원하지 않음

18. 센서 노드 OS[3] • Hardware 단계 • 기존의 센서노드 제품들 • 예) Tiny-OS, Nano-Q+ 등 • 센서노드와 센서의 분리가 보장되지 않음 • 센서 전원의 다양성이 지원되지 않음 • 결과, 기존 센서노드 플랫폼은 • 프로토타입 수준의 결과만을 지원 • 별도의 hardware을 개발해야 함 • 케이싱도 별도로 개발해야 함 => 이들을 모두 고려한 hardware 플랫폼이 요구됨

19. 센서 노드 OS[4] • Hardware Abstraction Layer • Nano-Q+ HAL의 경우 • 100개 이상의 함수 존재 • 각각의 센서/구동기마다 • 별도의 초기화 및 구동 함수 보유 • TinyOS • 마찬가지 • 센서 인터페이스에 대한 HW 추상화 부재 => 센서 관련 HW 추상화를 통한 HAL 제공

20. 센서 노드 OS[5] • 센서 드라이버 관리체계 • Nano-Q+나 Tiny-OS나 • 센서 디바이스 드라이버를 동적으로 연결, 구성하는 기능 없음 • 센서 드라이버만 변경할 수 없고 • 응용 + OS + 센서 드라이버를 함께 컴파일, 로딩 • 기존 OS 들은 드라이버 관리 체계 없음 => 센서 드라이버 관리 체계 요구됨

21. 센서 노드 OS[6] • 응용 API layer • Nano-Q+ • 일원화된 디바이스 관리 API 없음 • 각 트랜스듀서에 별도의 API 존재 • Tiny-OS, Ants, uCOS • 마찬가지 • 리눅스나 윈도우 • 일원화된 디바이스 관리 API 지원 • 예) open(), close(), read(), write(), ioctl() 등 • 일원화된 디바이스 관리 API 필요

22. IEEE1451[1] • 개 요 • 센서의 투명성 지원을 위한 표준 모델 제시 • a hardware-independent abstraction layer • for the sensor interface and • defines how the model is mapped • through a network abstraction layer to the control network. • a standardized software interface • for connecting NCAP to TIM • NCAP: Network Capable Application Processor • TIM: Transducer Interface Module

23. IEEE1451[2]

24. IEEE1451[3]

25. IEEE1451[4]

26. Transducer Electronic Data Sheet[1]

27. Transducer Electronic Data Sheet[2]

28. Transducer Electronic Data Sheet[3]

29. 우리의 관심분야 1451 표준의 문제점 • 1451표준의 USN 적용 • 1451 TIM은 자체가 센서노드임 • 예를 들어 1451.5 TIM • ZigBee 센서노드와 동일 • 별도의 전원을 사용 • 어떻게 쉽게 구현할 것인지는 의문 • 1451의 목표가 너무 광범위 • ZigBee의 Coordinator => NCAP • ZigBee의 센서노드 => TIM • 시장에 적용되기 어려움 • 우리의 목표에도 맞지 않음

30. 3. 센서 디바이스 관리 시스템 • 전체 구조 • 센서 디바이스 추상화 • 센서 접근 통합 API • 센서 디바이스 메니저 • 센서 HAL

31. 응용 개발자 센서 응용 표준화된 API 기반 센서 디바이스 공급자 플랫폼 공급자 저가격/고성능SN 플랫폼 Sensor 및 디바이스 드라이버 전체 구조[1] • 3 개발 주체 B B

32. 전체 구조[2] 응용개발자 센서공급자 플랫폼 공급자

33. 전체 구조[3] • 센서 접근 API: 응용 개발자 사용 • open(), close(), read(), write(), ioctl() 등 • 센서노드 플랫폼에 센서를 연결하고 • 센서노드 OS에 디바이스 드라이버를 삽입 • 센서 디바이스 드라이버: 센서 공급자 제공 • HAL 및 OS 제공 라이브러리를 이용 드라이버 제작 • 센서 HAL: 플랫폼 공급자 제공 • 센서 HW의 다양성을 추상화 • 드라이버 작성 시에 HAL을 활용 • 센서 디바이스 메니저: 플랫폼 공급자 제공 • API와 디바이스 드라이버를 연결 • HAL의 하드웨어 사상을 지원 • 센서노드 플랫폼: 플랫폼 공급자 제공 • 센서 HAL + 센서 디바이스 메니저

34. 센서 추상화 USN 응용 Application Programming Interface(API) 센서 Mgmt. ThreadMgmt. MemoryMgmt. TimeMgmt. 센서 Device Driver Hardware Abstraction Layer(HAL) 센서 HAL 센서 HW 인터페이스 MCU RF Power 센서 HW 센서 인터페이스 추상화 전체 구조[4] • 센서노드 플랫폼 • 응용개발자 와 센서공급자에게 투명성 제공 • 센서 추상화: API를 기반으로 응용개발자에게 제공 • 센서 인터페이스 추상화: 센서 Mgmt., 센서 HAL, 센서 HW 인터페이스 기반으로 센서제공자에게 제공

35. 전체 구조[5] • 센서 추상화 • 센서가 변경돼도 응용은 무관 • 예) 온도 센서 응용 프로그램 • LM61이 LM35로 변경됐을 때 => LM35의 디바이스 드라이버를 삽입, 응용 변경 없음 • 센서 인터페이스 추상화 • 플랫폼이 변경돼도 디바이스 드라이버는 무관 • 예) 온도 센서 응용 프로그램 • 플랫폼이 ATmega128에서 MSP430으로 변경 => OS 만 변경, 디바이스 드라이버 변경 없음

36. 센서 HW 인터페이스 추상화[1]

37. 센서노드플랫폼 PA0 전원 스위치 MCU (ATmega128) PF0(ADC0) 온도센서 (LM61) 센서 HW 인터페이스 추상화[2] • 온도 센서(LM61) 프로그래밍 분석 • HW: MCU + 전원 스위치(3V) + LM61 • PA0 포트: 전원을 제어하는 일반 포트 • PF0포트: ADC 입력을 받는 포트 • SW: 센서 처리 및 응용 관련 • ADC포트 설정: 채널 타입 및 프리스케일러 등 설정 • ADC 가 complete될 때까지 loop • X = ADC 값을 읽는다 • 실제 온도값으로 변환: 온도 = (100 * X) /1024[C] • 통신 라이브러리를 이용 전송

38. 센서 HW 인터페이스 추상화[3] • 센서 독립적인 부분: 플랫폼에서 지원 • HW: MCU + ADC 포트 제어 + 전원 제어 • SW의 경우 • ADC포트 설정: 채널 타입 및 프리스케일러 등 설정 • ADC 가 complete될 때까지 loop • X = ADC 값을 읽는다 • 통신 라이브러리를 이용 전송 • 센서 종속적인 부분: 센서 드라이버에서 지원 • HW: 센서 및 센서 부속 회로 • SW의 경우 • 실제 온도값으로 변환: 온도 = (100 * X) /1024[C]

39. 센서 HW 인터페이스 추상화[4] • 센서 인터페이스 => 플랫폼 처리 방법 • ADC 전압 => ADC 포트 직접 연결 • ADC 미약전압 => 증폭 후 ADC 포트 연결 • ADC 전류 => 저항 연결 후 ADC 포트 연결 • ADC 미약전류 => 증폭, 저항 연결 후 ADC 포트 연결 • 주파수 입력 => 폴링 포트 연결 • 인터럽트 => 인터럽트 포트 연결 • SPI => SPI 포트 연결 • I2C => I2C 포트 연결 • 직렬 => 직렬 포트 연결 • 센서종속 회로 • 센서 제작자가 구현

40. 센서 HW 인터페이스 추상화[5] • 사용전원 • V0: 잔원 공급 없음 • V1: 2.7~3.3V • V2: 4.5~5.5V, • V3: 7V • V4: 9V • V5: 12V • V6: 24V • 센서노드 플랫폼 구성 • 예) ADCV/V1 2개 + INTR/V1 1개 + 직렬/V2 1개 • 시장의 요구에 따라 적절한 플랫폼 개발 및 상품화 • 사용자는 off-the-shelf 방식으로 구매 • 세계 시장에 진출 => 규모의 경제 실현

41. 센서 HW 인터페이스 추상화[6] • 센서 HW 인터페이스의 wire 수 • 인터페이스의 HW 포트 지정 • 4가지 형태의 인터페이스들 • 1 wire interfaces • adcv, adcwv, adca, adcwa, freq • 2 wire interfaces • i2c • 3 wire interfaces • serial • 4 wire interfaces • spi

42. 센서 HW 인터페이스 추상화[7] • 센서 디바이스 HW 추상화 • 탈부착이 가능한 소켓 형식의 인터페이스 • 인터페이스 9종 • 구동기도 포함하여 추상화 • 추상화 사례 • 이름: ADCV/V1 • attribute: 16비트 integer • functions: • port-adcv-init()’ • port-adcv-getdata(); • port-adcv-setdata(); • port-adcv-onoff(); • constraints: • 10비트 ADC 지원 • 입력전압 0V ~2.56V 지원

43. 센서 HW 인터페이스 추상화[8] • 인터페이스 naming • 센서노드 플랫폼 구성 • 예) ADCV/V1 2개 + INT/V1 1개 + 직렬/V2 1개 • 플랫폼에 인터페이스 이름 표시 • adcv_v1_0 vs. int0 • adcv_v2_1 vs. int1 • int_v1_0 vs. int2 • serial_v2_0 vs. int3 • HAL 접근 시 이름 활용

44. 센서 접근 통합 API[1] • 응용프로그래머에게 센서의 추상화 제공 • 3가지 추상화 제공 • 센서, 이벤트 센서, 구동기 • 센서 • open시에 전원 on 및 초기화 • read시에 센싱 데이터 입력 • close 시에 전원 off • ioctl 을 이용 파라미터 변경 가능 • write 사용 불가 • 이벤트 센서 • open 및 close, ioctl은 센서 와 동일 • read 및 write 사용 불가 • ioctl을 사용 이벤트 발생 시 처리 함수 등록 • 구동기 • open, close, ioctl은 센서와 동일 • read 사용 불가 • write 시, 적절한 값을 구동기에 보낸다. • 값의 의미는 구동기에 따라 다름

45. Open() driver_Open() 디바이스 응용 프로그램 Close() driver_Close() Read() driver_Read() Write() driver_Write() Iotcl() driver_Iotcl() I/O 서브시스템 디바이스 드라이버 UNIFORM_IO_DRV 실제 디바이스 구현 센서 접근 통합 API[2] • I/O 서브 시스템 • 센서 I/O 서브시스템에 API셋을 정의한다 • 디바이스 드라이버에서 정의된 API셋의 함수 구현 • 디바이스 드라이버는 센서 I/O 서브시스템에 응용에 필요한 함수만 등록 • 센서 I/O 서브시스템은 API셋과 각 디바이스 관련 센서 I/O함수를 연동

46. 센서노드 플랫폼 adcv_v1_0 adcv_v1_1 adcv_v2_2 seri_v2_0 온도센서 DD 조도센서 DD 가속도센서 DD 온도 센서 조도 센서 가속도 센서 센서 접근 통합 API[3] • 응용 개발자가 할일 • 센서 구입 => DD 확보(센서공급자 제공) • 플랫폼 구입 => 센서 장착 • 응용 프로그램 작성 • 디바이스 드라이버 삽입 및 센서 장착 인터페이스 지정 • 초기화 때 device_connect() 시스템 콜 호출 • 이후 open(), close(), read(), write() 등 활용

47. 센서 접근 통합 API[4] • 응용 프로그램 작성 • 예) 온도 센서, 센서 • fd = open(“Temp_Sensor”, SENSOR); • 리턴된 fd 값으로 디바이스 접근 • Linux와 비슷한 방식 • close(fd); nbytes = read(fd, &buf, bytes); • 센서 디바이스 연결 정의 • 예) 온도 센서, LM61 • 디바이스 드라이버 입수: lm61_drv_pt device_connect(“Temp_Sensor”, “adcv_v1_1”, lm61_drv_pt);

48. 센서 Device Driver[1] • 센서공급자가 작성 • 적절한 드라이버만 작성 • 센서: open(), close(), read(), ioctl() • 이벤트센서: open(), close(), ioctl() • 구동기: open(), close(), write(), ioctl() • 나머지는 NULL로 등록됨 typedef struct { INT8U (*Open)(void); void (*Close)(void); INT8U (*Read)(void* pdata, INT8U size); INT8U (*Write)(void* pdata, INT8U size); INT8U (*Ioctl)(void* pdata, INT8U size); } UNIFORM_IO_DRV;

49. 센서 Device Driver[2] • 온도 센서 응용 예 INT8U fd, n; INT16U buf; device_connect(“Temp_Sensor”, “adcv_v1_1”, lm61_drv_pt); fd = open(“Temp_Sensor”, SENSOR); n = read(fd, &buf, sizeof(buf)); close(fd); • 디바이스 메니저는 • device_connect()에서 인터페이스와 드라이버를 Temp_Sensor 에 지정 • 결과는 Transducer Device Table(TDT)에 저장 • open()에서 “Temp_Sensor”, SENSOR 등 TDT에 저장 • 그 후, lm61_open() 드라이버 함수 호출 • close(), read(), ioctl() 등도 마찬가지로 처리

50. 센서 Device Driver[3] • 디바이스 드라이버(Temp-Sensor) 사례 extern INT8 fd; // fd 는 OS가 제공함 INT8U Temp_Sensor_Open(void) { hal_adcv_init(fd);       hal_adcv_onoff(fd, ON);       PutString(“Temp Sensor Open\r\n");        return fd; } void Temp_Sensor_Close(void) {         hal_adcv_onoff (fd, OFF);         PutString(“Temp Sensor Close\r\n");         return 0; } INT16U Temp_Sensor_Read(Read_Data *pData, INT8U size) {         INT16U t, temp;         t = hal_adcv_getdata(fd);         temp = (100 * t)/1024; // 10비트 값을 온도로 변환         memcpy(pData, &temp, size); return size; }