팀번호: XX	이곳에 프로젝트 아이템명을 쓰시오	version v0.1	네트워크보안프로그래밍 (졸업작품 프로젝트)

2023 가천대학교, 설계서

(AIoT 트랙용)

이곳에 프로젝트 아이템명을 쓰시오 !

설 계 서

2023.X.X

가천대학교 컴퓨터공학과

팀장 ▪ 홍길동(2016XXXXXXX)

팀원 ▪ 홍길순(2017XXXXXXX)

팀원 ▪ 홍길순(2015XXXXXXX)

팀원 ▪ 홍길순(2015XXXXXXX)

문서 정보

본  문서는 AIoT트랙용으로 OOOOOOOOO OOOO 개발을 위한 요구규격 및 설계서입니다.

버 전	0.1
작성일	2023-9-17
상 태	□완료 □진행 중 ■초안

버전	변경한 사람	변경한 날짜	버전업 변경(또는 추가)내용
0.1	이병문교수	2023-09-01	요구규격 및 설계서 양식(템플릿) 정의
0.2	홍길동		OOOO OOOO OOOO 작성
0.3			OOOO OOOO OOOO 작성
0.4			OOOO OOOO OOOO 작성
0.4
0.5
0.6
0.7
0.8
0.9
1.0			설계서 작성 완료

목  차

	1. 프로젝트 개요
		1.1 개발목표와 범위	...................................................										3
		1.2 개발일정/산출물	...................................................										4
		1.3 개발조직/역할	...................................................										4
	2. 요구사항 정의
		2.1 서비스 구성 및 개요		.............................................									5
		2.2 서비스 유스케이스 모델				..........................................							7
		2.3 요구기능 정의(IoT디바이스)(HW,SW)								......................			11
		2.4 요구기능 정의(모바일용)						...................................					17
		2.5 요구기능 정의(웹관리자용)						..................................					34
	3. IoT디바이스 설계
		3.1 보드 및 센서규격					...................................						44
		3.2 회로도 설계								......................			45
		3.3 하우징(외관케이스) 설계									.....................		52
	4. 센서데이터 분석 및 지능화
		4.1 센서데이터 추출 및 필터링					.....................................						76
		4.2 센서데이터 특징 및 전처리			............................................								77
		4.3 지능화처리 방안(AI방식 또는 알고리즘방식)										................	79
	5. 화면(UI)설계
		5.1 사용자 메뉴구성(모바일)					.....................................						90
		5.2 초기화면(로그인 전화면)설계					....................................						91
		5.3 사용자 화면설계(모바일)					....................................						92
		5.4 관리자 메뉴구성					...................................						120
		5.5 관리자 화면설계(웹)					....................................						121
	6. 프로세스(기능) 설계
		6.1 시스템 아키텍쳐					...................................						150
		6.2 사용자 기능설계(Sequence Diagram)									......................		151
		6.3 관리자 기능설계(Sequence Diagram)									.....................		180
		6.4 IoT디바이스 기능설계(Activity Diagram)										...............	209

	7. API 설계
		7.1 서버/클라이언트/디바이스 구조			..................................						210
		7.2 REST API 정의(서버용,모바일용,IoT디바이스용)								................	211
		7.3 REST API 설계(서버용)		.....................................							213
		7.4 REST API 설계(모바일용)		.....................................							228
		7.4 REST API 설계(IoT디바이스용)		.....................................							232
	8. 데이터 설계
		8.1 ERD	................................................................								243
		8.2 논리적설계(테이블명세서)							.......................		244
		8.3 로그파일 설계					.................................				250
		8.4 오류코드 및 오류파일 설계						.............................			255
	9. 성능시험지표
		9.1 서비스 성능평가지표				...................................					260
		9.2 IoT디바이스 성능평가지표				...................................					262
	10. 개발환경구성
		10.1 개발환경				.....................................					267
		10.2 소스디렉터리 구조				.....................................					268
		10.3 명칭표준안(변수,함수,파일명 등)				.....................................					270

프로젝트 개요

개발목표와 범위

■ 개발목표

본 설계서는 OOOO 환경에서 OOOOO를 위한 OOOO 서비스를 개발하기 위한 설계서이다. 주로 사용자는  OOOO 이며, 모바일(스마트폰)을 통해서 접속하고 사용하기 편리하도록 고안되는 것을 전제로 한다. OOOO 서비스를 효과적으로 관리하기 위해 관리기능도 구성하였으며 최대한 편리성과 OOO을 추구할 수 있도록 개발한다.

아래 그림1-1은 본 서비스의 전체적인 구성을 나타내며, 3종류의 사용자가 본 서비스를 사용한다.    (아래 그림처럼 각팀별로 ppt로 그리고, 캡쳐해서 넣을 것. 단, 본문의 글씨크기와 그림속의 글씨크기가 같아야 하며, 그림화질이 선명하여야 함)

그림 1.1 모바일 플랫폼의 설계범위

■ 개발필요성

본 서비스는 OOO OOO OOO (필요성을 제시한다).

개발일정/산출물

본 설계서는 아래 그림2-1과 같이 개발일정에 따라 진행하며, 각 단계별로 산출물을 개발한다.   (아래 그림처럼 각팀별로 ppt로 그리고, 캡쳐해서 넣을 것. 단, 본문의 글씨크기와 그림속의 글씨크기가 같아야 하며, 그림화질이 선명하여야 함)

그림 1.2 개발일정 및 산출물

개발조직/역할

역할	이름	역할(개발기능)	비고
팀장
팀원
팀원
팀원

요구사항 정의

서비스 구성 및 개요

(여기서는 서비스 시나리오 구성도를 그린다. 즉, 팀이 만들고자 하는 IoT서비스를 위해 IoT디바이스, 모바일, 서버간의 구성도를 그리고, 각각 어떤 서비스를 어떠한 절차로 제공하여 어떤 효과를 얻게 되는지 그림으로 그리고 설명한다. 특히,  AI학습서버와 AI서비스를 분리하여야 한다.)

그림 2.1 서비스 시나리오 구성도

① IoT스마트 방범기기는 침입자가 10cm 이내로 근접하는지를 0.5초간격으로 모니터링하며 근접한 물체나 인체가 탐지된 경우에 0.1초동안 부져음을 울리고 IoT스마트 관제기기로 이 사실을 REST API방식으로 알린다.

② IoT스마트 관제기기는 침입사실을 IoT스마트 방범기기로부터 통지받으며 파랑색 LED를 켜고 관제DB에 기록한다. 또한, IoT스마트 탐지기기에게 REST API 방식으로 정밀탐지를 명령한다.

③ IoT스마트 탐지기기는 정밀탐지를 요청받자마자 사운드센서를 동작시켜 침입자가 의 움직임을 적극적으로 모니터링하며 지정된 소리크기(임계치 = 500)이상이 측정되는지를 모니터링한다. 500이상을 넘을 경우 이 사실을 통합관리서버로 알린다.

④ 통합관리 서버는 ...... 어쩌구... 저쩌구... 설명을 흐름에 맞도록 시나리오를 작성한다.

서비스 유스케이스 모델

(여기서는 Use case 모델을 그리고, 설명한다. 단, 이때 액터를 정의하고, 주요기능이 유스케이스로 표현되어야 한다. 특히, AI학습서버, 데이터수집, AI서버가 표시되어야 한다.

그림 2.2 사용자용 유스케이스 다이어그램

(여기서는 Use case 모델을 그리고, 설명한다. 단, 이때 액터를 정의하고, 주요기능이 유스케이스로 표현되어야 한다.)

그림 2.3 관리자용 유스케이스 다이어그램

요구기능 정의 (IoT디바이스)(HW, SW)

(IoT디바이스에서 개발하여야할 기능을 아래의 표와 같은 포맷으로 작성하여 요구사항을 자세히 기술한다. 아래 표는 예임)

번호	주요객체	상세기능	개발담당자
1)	환경설정모듈	환경설정 파일적용	홍길동
2)		센서/네트워크 초기화	박길동
3)		로그파일 생성 및 관리	박길동
4)	센서데이터 측정모듈	초음파센서 측정관리	박길동
5)		센서데이터 필터링	홍길동
6)		측정장애 오류로깅	이길동
8)	지능화 처리모듈	침입추정알고리즘	박길동
9)		칩임기록 경보알림	이길동
10)		칩임기록 DB저장관리	홍길동
11)	REST API	IoT디바이스 리부팅요청 API	홍길동
12)		센서데이터 삭제요청 API	박길동

1) 환경설정 파일적용

▪ IoT디바이스가 동작하기 위해 필요한 환경설정정보를 파일로 저장하고, 관리하도록 한다.

▪ 파일은 JSON포맷의 sleepd.conf 파일로 정하여야 한다.

▪ 환경설정 변수에는 로그레벨, 기상시간, 절전시간, 센서별 측정주기글 저장하여야 한다.

2) 센서/네트워크 초기화

▪ OOO 디바이스의 네트워크 통신 모듈과 센서를 활성화시키야 한다.

▪ 부팅후에는 동작모드가 초기모드로 셋팅한다

▪ 네트워크 초기화에서는 서버로부터 할당받은 IP주소, Port주소를 NFC Tag에 Write하여, 추후 필요한 정보를 다시 사용할 수 있도록 하여야 한다.

나머지 부분은 상세기능 별로 번호를 붙여가며 정의한다.

요구기능 정의 (모바일용)

(위에서 그린 Use case 모델내의 주요기능을 이곳에서 좀더 상세하게 식별하고 표현한다. 샘플을 참조하여, 자세히 작성한다.)

번호	주요기능명	상세기능명	개발담당
1)	사용자인증	서비스 가입신청	홍길동
2)		로그인/로그아웃	홍길동
3)		비밀번호 변경	홍길동
4)		아이디/비밀번호 찾기	홍길동
5)	바이오문진서비스	바이오 정보 입력	박길동
6)		바이오 정보 조회	박길동
7)	사이버회진서비스	사이버회진 정보 조회	박길동
8)		중요 소견서 알림	홍길동
9)	힐링식단서비스	힐링 식단표 조회	홍길동
10)		식단표 푸시 알림	박길동
11)		식단 상세보기	홍길동
12)	건강커뮤니티	구성원간 정보 교류	홍길동
13)		기관 내 커뮤니티 공지	박길동
14)	확대 기능	실버세대를 위한 돋보기 기능	홍길동
15)	환경설정	로그인 설정	박길동
16)		계정 설정	박길동
17)		서비스 설정	홍길동

요구기능 정의 (웹관리자용)

(위에서 그린 Use case 모델내의 주요기능을 이곳에서 좀더 상세하게 식별하고 표현한다. 샘플을 참조하여, 자세히 작성한다.))

번호	주요기능명	상세기능명	비고
1)	사용자인증	서비스 가입신청	홍길동
2)		로그인/로그아웃	박길동
3)		비밀번호 변경	박길동
4)		아이디/비밀번호 찾기	박길동
5)	담당 실버사용자 모니터링	이름을 통한 검색	홍길동
6)		소속기관을 통한 검색	홍길동
7)		위험 환자 알림	박길동
8)		바이오정보 조회	박길동
9)	간단 소견서 관리	간단 소견서 입력	박길동
10)		간단 소견서 검색	홍길동
11)		중요 소견서 설정	홍길동
12)	관심 실버사용자 관리	관심 실버사용자 등록 및 해지	박길동
		관심 실버사용자 검색	홍길동
13)	담당 실버사용자	위험수치 푸시알림	홍길동
14)	환경설정	로그인 설정	박길동
15)		계정 설정	홍길동
16)		서비스 설정	홍길동

IoT디바이스 설계

보드 및 센서규격

(디바이스의 메인보드와 사용할 모든 센서부품에 대한 규격을 아래의 예와 같은 형식으로 작성한다.)

기기를 개발하기 위해 Open Source 하드웨어인 Raspberry Pi 4를 사용한다. 64bit ARMv7 Quad Core CPU, 1G RAM을 지원하고 다양한 센서와 다중센서를 동시 처리하는 컴퓨팅 파워를 제공한다. 네트워크 및 모바일 애플리케이션과 통신하기 위한 WiFi모듈과 수면 정보 및 코골이 측정을 위한 GPIO 인터페이스를 지원한다. 하드웨어의 사양은 표 2. 과 같다.

<그림 3.x> Raspberry Pi 4

항목	사양
Processor Chipset	Boardcom BCM2837 64bit Quad Core Processor Powered Single Board Compute running at 1.2GHz
Processor Speed	Quad Core @ 1.2 GHz
1RAM	1GB SDRAM @ 400MHz
Storage	MicroSD
USB 2.0	4x USB Port
Max Power/voltage	2.5A @ 5V
GPIO	40Pin
Ethernet Port	지원
Wi-Fi	Built in
Bluetooth 4.1	Built in

<표 3.1 > Raspbeery Pi 3 Spec

￭ 사운드 센서 (LMV324)

수면케어 디바이스에서 코골이를 측정하기 위해 사운드 센서를 이용한다. 이 센서는 LMV324 칩을 이용한 소리감지 센서이다.  이와같은 스타일로 기기에서 사용하는 모든 센서모듈과 액츄레이터 모듈을 설명하고 도식한다. 산출되는 정보를 바탕으로 코골이에 대한 정보를 측정한다. 또한 가변센서를 이용해 감도를 조절 할 수 있다.

<그림 2.4> 사운드 센서 (LMV324 Chip)

<그림 2.18> 사운드 센서에서 측정되는 값

항목	사양
Working Voltage Range	2.7V ~ 5.5V
Gain Bandwidth	1.2MHz
Slew rate	1.5V/㎲
Work temperature	-40℃ ~ 125℃

<표 2.2> LVM324 Spec

회로도 설계

(아래와 같은 그림을 그리고, 각 센서와 보드간의 연결핀 구성을 작성한다.)

그림 3.X  회로 구성도

하우징(외관케이스) 설계

(만들 디바이스의 외관을 (아래와 같은 스타일로) ppt 로 그리고, 캡쳐한후, 자세히 설명한다.)

OOOOO .... OOOO ..... OOOO .... 라즈베리파이를 바닥면에서 떨어뜨린 이유는 라즈베리파이를 바닥에 직접적으로 닿지 않도록 함으로써 전기적인 접촉 또는 간섭 문제를 예방할 수 있다. 바닥과의 일차적인 접촉을 피함으로써 배선과 모듈들이 안전하게 배치되고 충돌이나 간섭으로 인한 문제를 줄일 수 있다. 3D 프린터로 작업하는 하우징의 두께는 모두 2mm로 통일한다.

<그림 3.15> 옆에서 바라봤을 때의 하우징 내부 모습

OOOO.... OOO....  그림 3.15는 옆에서 바라봤을 때의 컨트롤러 하우징 내부 모습을 보여준다. 하우징의 높이는 모두 동일하게 40mm로 제작된다. 그림 3.14는 하우징을 옆에서 바라봤을 때의 외부 모습을 보여준다. 하우징 한쪽 가로 부분에는 20mm × 13mm(가로 × 세로)의 구멍이 뚫려 있다. 이 구멍은 수면매트와 컨트롤러 간의 연결을 위한 DP 케이블을 통과시키기 위한 것으로, DP 케이블을 이용하여 수면매트와 컨트롤러의 PCB를 연결할 수 있게 해준다. 추가로 반대편에는 라즈베리파이에 전원을 공급하기 위한 10mm × 7mm(가로 × 세로)의 구멍도 마련되어 있다. 랜선을 연결하는 구멍을 마련하지 않은 이유는 본 수면매트 컨트롤러가 와이파이를 통해 작동되기 때문에 랜선 연결이 필요가 없기 때문이다. 하우징의 아랫부분에 나사 구멍을 4개 만들어 PCB를 고정시키고, 옆면에 여섯 개의 기둥을 세워 하우징 덮개의 기둥 역할을 한다. 그림 3.16은 옆에서 바라봤을 때의 하우징 외부 모습이다.

<그림 3.16> 옆에서 바라봤을 때의 하우징 외부 모습

센서데이터 분석 및 지능화

센서데이터 추출 및 필터링

(3.1에서 기술한 (사용할) 모든 센서들의 데이터의 특성을 분석한다. 그리고, 데이터를 어ᄄᅠᇂ게 추출할지(예, 샘플링주기, 정밀도, 등등)를 정하고, 오류가 발생할 때 필터링하는 방법을 제시한다.)

센서데이터 특징 및 전처리

(수집한 데이터를 활용하려면 필요한 특징(또는 학습용데이터)데이터가 필요하다. 데이터에서 특징을 어떻게 정의하고 식별해 낼지를 설명하고 설계하여야 하며, 그 내용을 작성한다. )

그림 3.X  데이트의 특징과 분포

지능화처리 방안(AI방식 또는 알고리즘방식)

(지능화 처리방안은  AI방식으로도 지능화할 수 있거나 또는 알고리즘방식으로도 지능화할 수 있다. 둘중에 한가지 방법으로 선택한다.  알고리즘방식은 임계치를 정해서 측정값의 변화에 따라 상황을 추정 또는 판단하는 방식이다. 따라서, 선택한 방식으로 자세히 설명한다)

화면(UI) 설계

사용자 메뉴구성(모바일)

■ 사용자

그림 5.X 사용자용  메뉴구조도

초기화면(로그인 전화면) 설계

(만약 모바일 화면일 경우에는 아래와 같은 스타일로 작성할 것. 반드시 프레임이 그림에 나오도록 캡쳐해야 한다.!)

	앱을 시작하면 최초로 나타나는 화면이다. 아이디와 비밀번호를 입력하고 버튼을 누르면 메인 화면으로 이동한다. 버튼을 누르면 서비스 가입 화면으로 이동한다. 버튼을 누르면 비밀번호 찾기 화면으로 이동한다. 버튼을 누르면 모바일 메인 화면으로 이동한다. 버튼을 누르면 어플리케이션이 종료된다. 버튼을 누르면 아무 동작도 나타나지 않는다.

(만약 웹화면일 경우에는 아래 규격을 따라서 작성할 것)

앱을 시작하면 최초로 나타나는 화면이다.

아이디와 비밀번호를 입력하고

사용자 화면설계(모바일)

( 4.1 스토리보드(메뉴)에서 식별된 모든  (사용자의) 메뉴의 화면이 그려져야 하며, 설계되어져야 한다. 모바일화면과 웹화면은 화면크기가 다르기 때문에  해당 스타일을 준수해서 (하나를 선택해서) 작성한다. )

■ 서비스 가입 화면(로그인 이전화면 - 실패) - 화면번호 A01

	이름, 연락처와 일치하는 정보가 DB내 존재한다면 가입 승인을 다음 화면과 같이 팝업창으로 나타낸다. 버튼을 누르면 로그인 화면으로 이동하고, 아이디/비밀번호가 자동으로 입력된다. 버튼을 누르면 모바일 메인 화면으로 이동한다. 버튼을 누르면 서비스 가입 화면으로 이동한다. 버튼을 누르면 아무 동작도 나타나지 않는다.

■ OO화면(비밀번호 찾기) - 화면번호 A02

	바이오 정보(체중)을 입력하는 기능을 제공한다. 텍스트 박스를 눌러 체중 값을 입력한다. 버튼을 누르면 음성 인식 팝업 창을 나타낸다. 버튼을 누르면 전송 확인 팝업 창을 나타낸다. 버튼을 누르면, 바이오 문진 서비스 화면으로 이동한다. 버튼을 누르면 확대 기능을 제공한다. 버튼을 누르면 모바일 메인화면으로 이동한다. 버튼을 누르면 바이오 문진 서비스 화면으로 이동한다. 버튼을 누르면 아무 동작도 나타나지 않는다.

■ 서브화면(비밀번호 변경-팝업창) - 화면번호 C28

(사용자 메뉴구성에서 식별된 모든 (사용자의) 메뉴의 면이 그려져야 하며, 설계되어져야 한다. 모바일화면과 웹화면은 화면크기가 다르기 때문에  해당 스타일을 준수해서 (하나를 선택해서) 작성한다. )

( 모든 메뉴의 화면이 반드시 그려져야 한다. ! )

( ppt 로 화면을 그린 후에 캡쳐해서 넣을 것!  그림속의 글씨크기가 너무

작지 않도록 주의할 것! )

관리자 메뉴구성

(관리자 메뉴구성에서 식별된 (관리자의) 모든 메뉴의 화면이 그려져야 하며, 설계되어져야 한다. 웹화면은 화면크기가 다르기 때문에  해당 스타일을 준수해서 (하나를 선택해서) 작성한다. )

■ 관리자

그림 5.X 관리자용 메뉴 구조도

관리자 화면설계(웹)

■ 서브화면(비밀번호 변경-팝업창) - 화면번호 C28

( (관리자의) 모든 메뉴의 화면이 그려져야 하며, 설계되어져야 한다.  )

( 모든 메뉴의 화면이 반드시 그려져야 한다. ! )

( ppt 로 화면을 그린 후에 캡쳐해서 넣을 것!  그림속의 글씨크기가 너무

작지 않도록 주의할 것! )

프로세스(기능) 설계

시스템 아키텍쳐

그림 2.1 시스템 아키텍쳐

그림 2.1을 보면 실버세대용 입을 이용하기 위해서 실버세대는 아이디와 비밀번호를

영양사는 실버사용자의 이름과 소속기관을 통해 바이오정보를 조회한다. 영양사는 실버사용자의 상세정보를 확인하고 관심환자로 판단될 경우 관심환자로 등록한다. 영양사의 편의를 위해 관심환자를 검색하는 기능을 제공한다.

영양사는 의사가 입력한 간단 소견서를 확인하고 웹을 통해 식단을 작성한다. 작성된 식단은 앱을 통해 확인한다. 식단뿐만 아니라 식단의 상세내용을 확인하는 기능을 제공한다.

환경설정에서 자동로그인 설정, 푸시 알림설정, 비밀번호 변경을 한다.

사용자 기능설계 (Sequence Diagram)

1) 서비스가입기능

(2.3절에서 정의된 모든 기능을 아래 쓰어진 그림과 설명처럼 사용자의 각 기능별로 Sequence Diagram을 그리고, 설명한다. 단, 반드시 서버와 클라이언트가 간의 주고받는 흐름을 보여주어야 한다. 그림속의 글씨는 본문의 글씨크기와 동일하여야 하며, 흐리지말고 명확하여야 한다. ppt 또는 UML툴로 그려서 캡쳐하여야 한다. ) 실버세대는 App Store 또는 Play Store에서 실버세대용 앱을 다운로드 받아 단말기에 설치하면 서비스 가입(개통)이 필요하다.  서비스가입 기능을 구현하기 위해 아래와 같이 설계한다.

그림 2.4 서비스 가입의 sequence diagram

그림 2.4를 보면 OOO  OOO OOO  OOOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO OO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO.

2) 로그인기능

(2.3절에서 정의된 모든 기능을 아래 쓰어진 그림과 설명처럼 사용자의 각 기능별로 Sequence Diagram을 그리고, 설명한다.  위의 내용과 동일한 지침임) 실버세대는 서비스 가입 후 어플리케이션을 실행하기 위해 제공받은 아이디/비밀번호를 이용한 로그인이 필요하다. 로그인 기능을 구현하기 위해 아래와 같이 설계한다.

그림 2.5 로그인의 sequence diagram

그림 2.5를 보면 서비스 가입상태가 되어있는 경우에 실버세대 사용자는 아이디/비밀번호를 입력 후 로그인 요청을 한다. 실버세대 앱은 실버세대가 로그인 버튼을 클릭하면 서버 인터페이스에 로그인 요청을 한다. 입력받은 정보를 바탕으로 서버 인터페이스는 PBR서버로 정보 조회 요청하고, PBR 서버에서는 요청받은 정보를 서버 인터페이스로 다시 되돌려 준다. 실버세대 앱은 서버 인터페이스로부터 받은 정보를 비교하여 승인이 되었을 경우 메인화면을 실버세대에게 나타낸다. 신청결과가 거부 되었을 경우, 실버세대에게 로그인 실패 메시지와 실패 사유를 함께 나타낸다.

3) OOO기능

(2.3절에서 정의된 모든 기능을 Sequence Diagram을 그리고, 설명한다. 위의 내용과 동일한 지침임)

그림

관리자 기능설계 (Sequence Diagram)

1) 서비스 승인

(2.4절에서 정의된 모든 기능을 아래 쓰어진 그림과 설명처럼 관리자의 각 기능별로 Sequence Diagram을 그리고, 설명한다. 단, 반드시 서버와 클라이언트가 간의 주고받는 흐름을 보여주어야 한다. 그림속의 글씨는 본문의 글씨크기와 동일하여야 하며, 이미지가 흐리지말고 명확하여야 한다. ppt 또는 UML툴로 그려서 캡쳐하여야 한다. ) .

그림 2.14 서비스 가입의 sequence diagram

그림 2.14을 보면 OOO  OOO OOO  OOOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO OO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO  OOO  OOO OOO

2) OO기능

(2.4절에서 정의된 모든 기능을 Sequence Diagram을 그리고, 설명한다. 위의 내용과 동일한 지침임)

(예를 들면, 2.4절에 15개의 기능을 식별하였다면,

15) OO기능 <- 이런식으로 작성한다. 1기능에 1페이지분량으로)

그림

IoT디바이스 기능설계 (Activity Diagram)

(2.4절에서 정의된 모든 기능이 포함되도록 아래의  Activity Diagram 그림을 ppt로 그려서 캡쳐한다.  단, Activity Diagram 표기법에 맞추어 그려야 한다. 그림속의 글씨는 본문의 글씨크기와 동일하여야 하며, 그림속의 글씨가 선명하게 나와야 한다. )

API 설계

서버/클라이언트/디바이스 구조

그림 7.1 서버 인터페이스 구조

본 설계는 그림 4.1에서처럼 사용자의 애플리케이션과 애플리케이션이 이용할 PBR서버의 데이터베이스를 연동하여 개발하기 위해 각 기능별로 Data API, Cashing Module, Security Module 구축에 대한 설계를 한다.

REST API 정의(서버용, 모바일용, IoT디바이스용)

( 서버와 클라이언트 간에 주고 받는 요청/응답의 모든 API를 식별하고 아래와 같이 정의한다. 단 URI는 반드시 명사형이어야 함! )

Method	URI	Description
GET	/device/metadata/all	전체 메타데이터 정보 요청
	/device/metadata/deviceid	디바이스ID 요청 (ex. 시리얼번호)
	/device/metadata/manufacturer	제작사 정보 요청 (ex. 제작회사, 디바이스명, 모델번호)
	/device/metadata/sensor	센서 정보 요청 (ex. 종류, 이름, 모델명, 사양, 단위)
	/device/metadata/actors	액츄레이터 정보 요청 (ex. 종류, 이름, 모델명, 사양, 단위)
	/device/metadata/system	OS, DB, 애플리케이션 정보 요청 (ex. OS/DB/Application 버전)
	/device/metadata/dataprofile	저장될 데이터 종류들 요청 (ex. PSQI 항목, 종류, 단위)
	.... (계속 정의 ... 함)	.....

Method	URI	Description
POST	/device/metadata/all	전체 메타데이터 등록
	/device/certification	수면케어 데이터서버에 등록
	/device/meta/<userid>/sleepstart	사용자별 수면측정 시작 요청
	/device/meta/<userid>/sleepfinish	사용자별 수면측정 종료 요청
	.... (계속 정의 ... 함)	.....

Method	URI	Description
PUT	/device/sdata/<userid>/all	사용자별 전체 환경설정정보 수정
	/device/sdata/<userid>/timer	디바이스 수면정보 측정주기 수정 (ex. 사운드 센서 측정주기)
	/device/sdata/<userid>/loglevel	디바이스 로그 레벨 수정
	/device/sdata/<userid>/dataexpire	수면정보 저장기간 수정
	... (계속 정의 ... 함)	...

Method	URI	Description
DELETE	/device/sdata/<userid>/all	사용자별 전체 환경설정정보 수정
	/device/sdata/<userid>/timer	디바이스 수면정보 측정주기 수정 (ex. 사운드 센서 측정주기)
	/device/sdata/<userid>/loglevel	디바이스 로그 레벨 수정
	/device/sdata/<userid>/dataexpire	수면정보 저장기간 수정
	... (계속 정의 ... 함)	...

REST API 설계(서버용)

( 7.2에서 정의한 모든 API를 아래 그림과 같이 자세하게 설계한다.)

GET			/device/metadata/sensor
		(모바일) (웹) 클라이언트				→		디바이스 센서정보 요청				→ (IN)	OOOOO OOOO 서버
						←			센서정보 결과 전송			← (OUT)
Parameter
	속성				전송방향					Type	Description
					IN		OUT
	userid				O						요청한 사용자아이디
	content_type						O			String	application/json
	result_code						O			int	처리결과 코드(200: 성공, 600: 오류코드)
	result_req						O			String	처리결과 오류메세지
	sensor_info						O			Array	센서 정보

실제 전송내용 (JSON 의 경우라면)

전송방향 : IN

{

“userid” : “sns_member”

}

전송방향 : OUT

{

"content_type" : "json" ,

"result_code" : 200 ,

"result_req" : "" ,

“sensor_info" :

[

[

"type" : "sound" ,

"name" : "LMV324 sound sensor" ,

"dimension" : “0.62cm x 0.6cm x 0.64cm" ,

"working_voltage" : "DC 2.7V - 5.5V" ,

"unit" : "dB"

]

]

}

REST API 설계 (모바일용)

( AI학습서버는 별도로 실행되는 서버이므로, 서버의 학습, 재학습, 데이터 재수집 등등 학습서버를 제어하기 위한 모든 REST API를 7.3의 포맷에 맞도록 자세하게 설계한다.)

REST API 설계 (IoT디바이스용)

( AI학습서버는 별도로 실행되는 서버이므로, 서버의 학습, 재학습, 데이터 재수집 등등 학습서버를 제어하기 위한 모든 REST API를 7.3의 포맷에 맞도록 자세하게 설계한다.)

데이터 설계

ERD

( ERD를 그리고, 캡쳐해서 아래와 같이 넣을 것 .)

( DB이름과 테이블이름을 표기할 것! )

논리적 DB설계 (테이블명세서)

( 6.1 ERD에 식별된 모든 테이블에 대해서 아래와 같은 스타일로 테이블명세서를 작성할 것..)

테이블명(상용구) :			SENTENCE
NO	Attribute	Data Type	NN	PK	FK	Description
1	STAFF_ID	VARCHAR(20)	O	O	O	담당자아이디
2	SYMBOL_ID	CHAR(8)	O	O		상용구번호
3	SYMBOL_CO	VARHCAR(500)				상용구내용

테이블명(식품) :			FOODS
NO	Attribute	Data Type	NN	PK	FK	Description
1	FODS_CD	CHAR(18)	O	O		식품코드
2	FODS_DIV_CD	CHAR(10)				식품분류코드
3	FODS_NM_KR	VARCHAR(50)				식품명_한글
4	FODS_NM_EN	VARCHAR(50)				식품명_영문
5	SERV_CAPA	NUMBER(4,2)				제공량
6	CALO	NUMBER(4,2)				열량
7	CBHD	NUMBER(4,2)				탄수화물
8	PRTN	NUMBER(4,2)				단백질
9	FAT	NUMBER(4,2)				지방
10	SUGR	NUMBER(4,2)				당류
11	SODM	NUMBER(4,2)				나트륨
12	CLST	NUMBER(4,2)				콜레스트롤
13	SFA	NUMBER(4,2)				포화지방산
14	TFA	NUMBER(4,2)				트랜스지방

로그파일 설계

( 모든 기능과 서비스가 정상동작하는지를 확인하기 위해 실행/운영로그정보를 파일로 저장하고, 관리하여야 하며, 어떠한 포맷으로 로그파일을 저장하고 운영하는지 설계하고 설명한다. 또한, 로그파일명도 정의한다. 아래 예 참조)

파일명 : ooooooo.log

레벨	형식	설명	비고
0	error	디바이스에서 발생하는 치명적인 오류를 포함
1	warn	디바이스에서 발생하는 일반적인 오류를 포함
2	info	디바이스에서 상태변경과 같은 정보성 메시지

Log 예시)

2023.02.20.23:29:30.11 [Info] 200 : 정상 처리, 비밀번호 검증 학습 모델 학습을 완료하였습니다.

2023.02.20.23:30:30.15 [Info] 200 : 정상 처리, 비밀번호 검증 학습 모델 배포를 완료하였습니다.

2023.02.20.23:31:30.11 [ERROR] 404 : 해당 파일을 찾을 수 없습니다. ‘./data/config.config’

2023.02.20.23:29:30.11 [Info] 200 : 정상 처리, 비밀번호 검증 학습 모델 학습을 완료하였습니다.

2023.02.20.23:30:30.15 [Info] 200 : 정상 처리, 비밀번호 검증 학습 모델 배포를 완료하였습니다.

2023.02.20.23:31:30.11 [ERROR] 404 : 해당 파일을 찾을 수 없습니다. ‘./data/config.config’

<표 8.x> Log 파일 설계

오류코드 및 오류파일 설계

( 발생할 수 있는 모든 오류를 식별하여 코드로 정의한다. (표형식으로) , 또한 오류가 발생할때마다 기록할 오류파일의 포맷과 파일명을 정의하고 설계한뒤에 자세히 설명한다. 아래 예참조)

코드 번호	설명	비고
200	정상 처리(성공)
000	정의되지 않은 에러코드
301	비밀번호 검증 학습 오류
302	비밀번호 검증 학습 모델 배포 오류
303	비밀번호 검증 학습 모델 버전 관리 오류
304	비밀번호 검증 학습 모델 사전 수정 오류
305	비밀번호 검증 모델 파라매터 수정 오류
306	인공지능 출입키 검증 오류
307	비밀번호 검증 학습 모델 삭제 오류
308	비밀번호 검증 학습 모델 정보 반환 오류
309	장애기록 반환 오류
310	비밀번호 검증 오류
311	비밀번호 검증 학습 모델 적용 오류

<표 8.x> 오류코드

301 에러 코드는 스마트 보안관제 서버에서 비밀번호 검증 학습 모델을 학습하는 과정에서 발생하는 오류이다.

302 에러 코드는 비밀번호 보안관제 서버와 스마트 도어락 게이트웨이에서 비밀번호 검증 학습 모델을 배포하는 과정에서 발생하는 오류이다. ........... ... ..

성능평가지표

서비스 성능평가지표

( 개발할 서비스의 성능을 제대로 측정하기 위한, 평가지표를 발굴하고, 아래와 같은 포맷으로 작성한다 )

평가항목	단위	개발목표치	평가방법
키보안레벨정확도	%	≥80	팀 자체시험

평가항목	키보안레벨정확도
시험내용	인공지능 출입키 암호검증 모듈은 비밀번호가 유추당할 확률을 측정하여 보안 수준을 측정한다. 이를 시험하기 위해 무작위로 수집한 비밀번호 목록에 대해 검증을 수행하도록 하고, 미리 정해둔 각 비밀번호 보안 수준에 대해 올바른 판단을 내리는지 수행한다. 비밀번호 1개당 10회 검증을 수행하며, 모두 올바른 결과로 출력하는지 확인한다.
시험환경	무작위로 수집한 비밀번호 목록 2. 인공지능 출입키 암호검증 모듈 3. 비밀번호 보안성 검증 결과 로그 4. 로그를 확인하기 위한 PC 환경
시험절차	시험은 사용자가 선택한 비밀번호가 유추 당할 확률을 측정하는 정확도를 판단하기 위해 진행한다. 이를 위해 보안성을 4단계로 분류한다. 보안성은 기존의 비밀번호 보안지표 3가지(LUDS, Levenshtein Distance, zxcvbn)를 사용하며 보안지표 0개 만족 시 보안성은 0, 1개 만족 시 보안성은 1, 2개 만족 시 보안성은 2, 전부 만족할 경우 보안성은 3으로 한다. 이에 대한 결과가 인공지능 출입키 암호검증 모듈이 예측한 결과와 일치하면 통과로 간주한다. 시험의 전체적인 진행은 다음과 같다. 무작위로 수집한 비밀번호 목록에서 1개의 비밀번호를 무작위로 선택한다. 선택된 비밀번호를 기존의 보안지표로 보안성 점수를 측정한다. 선택된 비밀번호를 인공지능 출입키 암호검증 모듈을 통하여 보안성 점수를 측정한다. 두 보안 점수를 비교하여 보안 점수가 같다면 성공으로 간주한다. 하나의 비밀번호 마다 10회 실시하며, 총 100개의 무작위로 선택된 비밀번호에 대해 80회 이상 성공이면 통과이다.

평가항목	단위	개발목표치	평가방법
모바일출입카드의 무결성유지율	%	≥95	팀 자체시험

평가항목	모바일출입카드의 무결성유지율
시험내용	암호화한 정상적인 출입키를 100번 전송하여, 95번 이상 정상으로 수신하거나, 또는 위조된 출입키를 100번 전송하여 95번 이상 수신 거보를 한다면 무결성이 유지된다. 이러한 조건이 모두 만족되면 성공으로 본다. <그림 6.2.1> 시험 내용
시험환경	모바일 출입카드가 설치된 안드로이드 휴대폰 도어락 어댑터 기능이 설치된 ESP32 로그를 출력하기 위한 노트북 해킹을 위한 2개 이상의 BLE 연결장치를 가진 컴퓨터(노트북)
시험절차	모바일 출입카드에서 도어락 어댑터로 BLE 전송보안모듈을 이용하여 100번 올바른 출입키 데이터를 전송한다. BLE 전송보안모듈에서 1번에서 전송받은 데이터를 검사하고 무결한 데이터로 판단한 횟수를 세어서 노트북 모니터에 출력한다. 해킹을 위해 준비한 컴퓨터로 모바일 출입카드와 도어락 어댑터에 각각 연결한다. 모바일 출입카드에서 데이터를 전송하면 해킹을 위해 준비한 노트북은 해당 정보를 위변조하여 도어락 어댑터에 전송한다. BLE 전송보안모듈에서 4번에서 전송받은 데이터를 검사하고 위변조된 데이터로 판단한 횟수를 세어서 노트북 모니터에 출력한다.

IoT디바이스 성능평가지표

( 개발할 IoT디바이스를 제대로 개발하기 위해, 측정할 성능평가지표를 정의하고, 목표값을 정의한 후, 어떻게 시험을 할지 방법을 작성한다 )

개발환경구성

개발환경

■ 서버

구분	개발환경	규격	비고
개발툴	편집툴	ATOM
	개발IDE	ENIDE
	프레임워크	Node.js
	사용할 미들웨어(모듈)	Express Router Jade OOO .OOO
서버	TCP Port주소
	IP주소
	OS	OOO
	DB	OOO
서버 하드웨어	CPU	Intel Core2Duo
	RAM	4G RAM
	DISK	500G DISK (SATAII)
	Network	100Mbps

■ 모바일

구분	개발환경	규격	비고
클라이언트	OS	OOO
		OOO
하드웨어	CPU	OOO
	RAM	OOO
	DISK	OOO
	Network	OOO

■ IoT디바이스

구분	개발환경	규격	비고
클라이언트	OS	OOO
		OOO
하드웨어	CPU	OOO
	RAM	OOO
	DISK	OOO
	Network	OOO

소스디렉터리 구조

그림 7.1 디렉토리 구조

그림 7.1과 같이 MVC 구조로 개발 디렉토리 구조를 정의하며, 그림 7.2와 같이 세부 디렉터리와 파일명으로 모듈화룰 정의한다.

그림 7.2  디렉터리 및 파일환경

명칭표준안(변수,함수,파일명)