임베디드 시스템의 트레이드 오프

임베디드 시스템의 절충
간행물 : Research> Ph. D. 논문 - 연례보고 연도 : 2014.
1 MB, PDF 문서.
같은 저자.
연속 흐름 미세 유체 바이오칩의 핀 수 감소.
출판물 : 연구 - 피어 리뷰> 저널 기사 - 연례 보고서 연도 : 2017.
유전체 회로 합성 및 최적화 된 기술 매핑에 대한 하향식 접근법.
출판물 : 연구 - 동료 심사 - 소송 절차 - 연례 보고서 연도 : 2017.
INTO-CPS를 사용한 배기 가스 재순환 수처리 시스템을 갖춘 임베디드 제어 소프트웨어의 분산 된 시뮬레이션
출판물 : 연구 - 동료 심사 - 소송 절차 - 연례 보고서 연도 : 2017.
결함 허용 흐름 기반 마이크로 유체 바이오칩의 빠른 아키텍처 수준 합성.
출판물 : 연구 - 동료 심사 - 소송 절차 - 연례 보고서 연도 : 2017.
IEEE Time-Sensitive Networking을위한 내결함성 토폴로지 및 라우팅 합성
출판물 : 연구 - 동료 심사 - 소송 절차 - 연례 보고서 연도 : 2017.

임베디드 데이터베이스 시스템 관리의 문제점.
하버드 대학의 마고 셀처 (Margo Seltzer).
Michael Olson, Sleepycat Software, Inc.
데이터베이스 구성 및 유지 관리는 역사적으로 복잡한 작업이었으며 종종 데이터베이스 디자인 및 응용 프로그램 동작에 대한 전문 지식이 필요했습니다. 임베디드 환경에서는 이러한 전문 지식과 지속적인 데이터베이스 유지 관리가 필요하지 않습니다. 이 백서에서는 임베디드 시스템에서 발생하는 데이터베이스 관리 문제에 대해 설명하고 Berkeley DB 아키텍처가 어떻게 이러한 문제를 해결하는지 설명합니다.
1. 소개.
데이터베이스 관리는 초기 구성과 지속적인 유지 관리의 두 가지 구성 요소로 이루어져 있습니다. 초기 구성은 데이터베이스 설계, 구현 및 조정으로 구성됩니다. 디자인의 인스턴스는 디자인을 테이블, 릴레이션 또는 객체로 분해하고 적절한 인덱스 및 그 구현 (예 : B 트리, 해시 테이블 등)을 지정하는 것을 포함합니다. 디자인을 튜닝하려면 로그 및 데이터 파일의 위치를 ​​선택하고, 적절한 데이터베이스 페이지 크기를 선택하고, 메모리 내 캐시의 크기를 지정하고, 멀티 스레딩 및 동시성의 한계를 지정해야합니다. 임베디드 시스템은 특정 환경과 일련의 작업을 정의하므로 초기 시스템 구성 프로세스에서 전문 지식을 필요로하며 시스템의 지속적인 유지 관리에 집중합니다. 이런 방식으로, 우리의 강조점은 Microsoft의 AutoAdmin 프로젝트 [3]와 Asilomar 저자 [1]가 중요한 미래 연구 분야로 확인 된 "노 - 노브 (no-knobs)"관리와 다른 프로젝트와 다릅니다.
이 논문에서는 Asilomar 보고서의 저자가 스마트 카드, 토스터 또는 전화기와 같은 장치에있는 데이터베이스 인 "gizmo"데이터베이스 [1]에 초점을 맞 춥니 다. 이러한 데이터베이스의 주요 특징은 해당 기능이 사용자에게 완전히 투명하고 아무도 명시 적 데이터베이스 작업 또는 데이터베이스 유지 관리를 수행하지 않으며 데이터베이스가 언제든지 중단 될 수 있으며 즉각적으로 복구해야한다는 것입니다. 장치는 언제든지 하드 리셋 될 수 있으며, 데이터베이스가 초기 상태로 돌아가고 데이터베이스의 의미 적 무결성이 항상 유지되어야합니다. 2 절에서는 임베디드 시스템에서 자동화해야하는 데이터베이스 관리자 (DBA)가 일반적으로 수행하는 작업에 대해 자세히 설명합니다.
이 논문의 나머지 부분은 다음과 같이 구성되어있다. 2 절에서는 내장 데이터베이스 지원에 대한 요구 사항을 설명합니다. 3 절에서는 Berkeley DB가 임베디드 시스템에 필요한 손쉬운 관리에 어떻게 도움이되는지에 대해 설명합니다. 4 절에서는 Berkeley DB의 임베디드 응용 프로그램에 대한 적합성을 향상시키는 새로운 기능에 대해 설명합니다. 5 장에서 풋 프린트 크기에 대한 논의를한다. 6 절에서는 관련 연구에 대해 논의하고 7 절에서 결론을 맺습니다.
2. 임베디드 데이터베이스 요구 사항.
2.1 사용자 관점.
임베디드 데이터베이스 분야에서는 초기 시스템 구성이 아닌 자동화 된 지속적인 유지 관리 작업이 필요합니다. 전통적으로 DBA가 수행하는 다섯 가지 작업이 있지만 임베디드 데이터베이스 시스템에서 자동으로 수행해야합니다. 이러한 작업으로는 로그 아카이브 및 교정, 백업, 데이터 압축 / 재구성, 자동 및 신속 복구, 처음부터 다시 초기화가 있습니다.
로그 보관 및 백업은 밀접하게 결합됩니다. 데이터베이스 백업은 모든 대형 데이터베이스 설치의 일부이며 로그 아카이브는 증분 백업과 유사합니다. 임베디드 시스템에서 백업 및 아카이브의 의미가 무엇인지는 분명하지 않습니다. 소비자는 VCR이나 냉장고를 백업하지 않지만 개인용 컴퓨터 나 PDA를 백업해야합니다. 이 문서의 나머지 부분에서는 기즈모 데이터베이스에 백업이 필요하다고 가정합니다 (수동으로 일부 셋톱 TV 시스템에서 학습 한 TV보기 액세스 패턴을 수동으로 다시 프로그래밍해야한다고 생각한 경우). 또한 사용자는 기즈모가 백업되고 있으며 명시 적으로 백업을 시작할 필요가 없다는 사실을 사용자가 인식해서는 안되기 때문에 이러한 백업은 거의 즉각적이거나 완전히 투명해야합니다.
데이터 압축 또는 재구성에는 전통적으로 정기적 인 데이터베이스 테이블 덤프 및 복원과 인덱스 재 작성이 필요했습니다. 임베디드 시스템에서 이러한 재구성은 자동으로 이루어져야합니다.
복구 문제는 몇 가지 예외를 제외하고는 임베디드 및 전통적인 환경에서 비슷합니다. 대용량 서버 설치에서는 몇 초 또는 몇 분의 복구가 허용되지만 어느 누구도 전화 또는 TV가 재부팅 될 때까지 기다릴 의사가 없습니다. 보관과 마찬가지로 임베디드 제품에서도 복구가 거의 즉시 이루어져야합니다. 둘째, 시스템을 재부팅하기보다는 완전히 다시 초기화하는 경우가 종종 있습니다. 이 경우 내장 데이터베이스를 초기 상태로 복원하여 모든 자원을 비워야합니다. 일반적으로 대용량 서버 시스템의 요구 사항은 아닙니다.
2.2 개발자 관점.
임베디드 시스템에 필요한 유지 보수가 필요없는 운영 외에도 기즈모 데이터베이스를 사용하는 "기즈모 (gizmos)"에서 일반적으로 발견되는 제한된 리소스에서 벗어나는 여러 가지 요구 사항이 있습니다. 이러한 요구 사항은 작은 설치 공간, 짧은 코드 경로, 긴밀한 애플리케이션 커플 링을위한 프로그래밍 방식 인터페이스 및 SQL 및 ODBC와 같은 인터페이스 오버 헤드 (시간과 크기면에서), 애플리케이션 구성 및 유연성, 완벽한 메모리 상주 동작 지원 (예 : 이러한 시스템은 파일 시스템없이 기즈모에서 실행해야 함), 멀티 스레딩을 지원합니다.
작은 풋 프린트와 짧은 코드 경로는 자명하지만, 프로그램 인터페이스 요구 사항이 논리적 결과라는 점은 분명하지 않습니다. ODBC 및 SQL과 같은 전통적인 인터페이스는 상당한 크기의 오버 헤드를 추가하고 여러 IPC 호출은 물론 작업 당 여러 개의 컨텍스트 / 스레드 스위치를 자주 추가합니다. 임베디드 제품에는 SQL이 가능하게하는 복잡한 쿼리 처리가 덜 필요할 수 있습니다. 대신, 임베디드 공간에서 응용 프로그램이 특정 작업을 위해 데이터베이스를 구성 할 수있는 기능이 일반적인 쿼리 인터페이스보다 더 중요합니다.
일부 시스템은 RAM 및 ROM 이외의 다른 저장소를 제공하지 않으므로 내장형 데이터베이스가 메모리 전용 환경에서 자연스럽게 작동해야합니다. 마찬가지로 오늘날 많은 임베디드 운영 체제는 단일 주소 공간 아키텍처를 제공하므로 모든 동시성을 필요로하는 응용 프로그램의 경우 단순한 멀티 스레드 기능이 필수적입니다.
일반적으로 임베디드 애플리케이션은 네이티브 운영 체제 지원이 엄청나게 다양하게 변하는 기즈모에서 실행됩니다. 예를 들어, 임베디드 OS는 사용자 레벨 처리 또는 멀티 스레딩을 지원할 수도 있고 지원하지 않을 수도 있습니다. 그렇더라도 특정 임베디드 애플리케이션에 필요할 수도 있고 그렇지 않을 수도 있습니다. 모든 응용 프로그램이 둘 이상의 제어 스레드를 필요로하는 것은 아닙니다. 임베디드 데이터베이스는 정책을 결정하지 않고 개발자에게 메커니즘을 제공해야합니다. 예를 들어 응용 프로그램의 스레딩 모델은 정책의 문제이며 데이터베이스 소프트웨어가 아닌 하드웨어, 운영 체제 및 응용 프로그램의 기능 집합에 달려 있습니다. 따라서 데이터 관리자는 멀티 스레딩 사용을 제공해야하지만 필요하지는 않습니다.
3. Berkeley DB : 임베디드 시스템 용 데이터베이스.
버전 2.X 이상은 Sleepycat Software에 의해 배포되며 동시성, 로깅, 트랜잭션 및 복구 기능을 추가합니다. 추가 기능의 각 부분은 독립적 인 모듈로 구현됩니다. 즉, 서브 시스템을 Berkeley DB 컨텍스트 외부에서 사용할 수 있습니다. 예를 들어, 잠금 서브 시스템은 비 DB 응용 프로그램에 대한 잠금을 구현하는 데 쉽게 사용할 수 있으며 공유 메모리 버퍼 풀은 주 메모리에서 데이터를 캐시하는 모든 응용 프로그램에 사용할 수 있습니다. 이 서브 시스템 디자인을 사용하면 설계자는 애플리케이션에 필요한 기능을 선택하여 메모리 풋 프린트를 최소화하고 성능을 극대화 할 수 있습니다. 이는 이전 섹션에서 언급 한 작은 풋 프린트와 짧은 코드 경로 기준을 다룹니다.
Berkeley DB가 dbm 대체품으로 성장하면서 주요 구현 언어는 항상 C 였고 인터페이스는 프로그래밍 방식이었습니다. C 인터페이스는 프로그래밍 방식 API가 이미 비용이 많이 드는 쿼리 인터페이스 (예 : Embedded SQL) 위에있는 계층 인 많은 데이터베이스 시스템과는 달리 기본 인터페이스입니다. 버클리 DB의 유산도 데이터 모델에서 분명합니다. 그것은 없다. 데이터베이스는 가변 길이 바이트 문자열로 지정된 구조화되지 않은 키 / 데이터 쌍을 저장합니다. 따라서 스키마 디자인 및 표현 문제는 응용 프로그램의 책임이므로 임베디드 환경에 이상적입니다. 응용 프로그램은 해당 데이터 형식, 표현, 인덱스 값 및 인덱스 관계의 사양을 완전히 제어 할 수 있습니다. 즉, Berkeley DB는 특정 데이터베이스 관리 시스템이 아닌 견고한 고성능의 키 저장 시스템을 제공합니다. 우리는 응용 프로그램에 더 잘 캡슐화 된 복잡한 범용 지원을 교환하면서 단순성과 성능을 염두에두고 설계했습니다.
Berkeley DB의 프로그래밍 방식 인터페이스의 또 다른 요소는 사용자 정의 가능성입니다. 응용 프로그램은 Btree 비교 및 ​​접두사 압축 함수, 해시 함수, 오류 루틴 및 복구 모델을 지정할 수 있습니다. 즉, 임베디드 응용 프로그램은 데이터 요구에 가장 잘 맞는 기본 데이터베이스를 조정할 수 있습니다. 마찬가지로, 전통적으로 데이터베이스 관리자 (예 : 복구, 덤프 / 복원, 아카이브)와 함께 번들로 제공되는 유틸리티는 라이브러리 루틴을 둘러싼 작은 래퍼 프로그램으로 구현됩니다. 즉, 유틸리티에 대해 별도의 응용 프로그램을 실행할 필요가 없습니다. 대신 독립적 인 스레드는 유틸리티 데몬으로 작동하거나 일반 쿼리 스레드는 유틸리티 기능을 수행 할 수 있습니다. Berkeley DB를 기반으로하는 많은 현재 제품은 체크 포인트, 교착 상태 감지 및 성능 모니터링과 같은 기능을 수행하는 독립적 인 스레드가있는 단일 대형 서버로 번들로 제공됩니다.
앞서 언급했듯이 임베디드 환경에서의 생활은 유연한 스토리지 관리가 필요합니다. Berkeley DB는 로그 파일이나 데이터 파일을위한 디스크 공간을 미리 할당 할 필요가 없습니다. 많은 상용 데이터베이스 시스템이 원시 장치를 완벽하게 제어하지만 Berkeley DB는 일반 파일 시스템을 사용하므로 다른 프로그램과 데이터 공간을 안전하고 손쉽게 공유 할 수 있습니다. 모든 데이터베이스 및 로그 파일은 호스트 환경의 원시 파일이므로 환경에서 제공하는 유틸리티를 사용하여 데이터베이스 파일을 관리 할 수도 있습니다.
Berkeley DB는 공유 정보 관리를 위해 세 가지 메모리 모델을 제공합니다. 응용 프로그램은 IEEE Std 1003.1b-1993 (POSIX) mmap 인터페이스를 사용하여 데이터를 공유하고, shmget 인터페이스 패밀리가 자주 제공하는 시스템 공유 메모리를 사용하거나 프로세스 별 힙 메모리 (예 : malloc)를 사용할 수 있습니다. . 영구 저장소가 필요없고 공유 메모리 기능을 제공하지 않는 응용 프로그램은 엄격하게 개인 메모리를 요청하고 모든 데이터베이스가 메모리 상주라는 지정으로 Berkeley DB를 계속 사용할 수 있습니다. 이것은 순수 메모리 연산을 제공합니다.
마지막으로, Berkeley DB는 빠른 시작을 위해 설계되었으므로 시스템 초기화의 일부로 자동 복구가 가능합니다. 이것은 기즈모가 갑자기 종료되고 다시 시작되는 환경에서 Berkeley DB가 올바르게 작동 함을 의미합니다.
4. 임베디드 환경을위한 확장.
4.1 자동 압축.
응용 프로그램에서도 비교 및 ​​해시 함수를 지정할 수 있으므로 응용 프로그램에서는 압축되지 않은 텍스트 데이터 또는 압축 및 암호화 된 데이터를 기반으로 데이터를 구성 할 수 있습니다. 애플리케이션이 처리 된 형태 (즉, 압축 및 암호화)로 데이터를 비교해야한다고 지시하면 압축 및 암호화가 개별 데이터 항목에 대해 수행되고 메모리 내 표시는 이러한 특성을 유지합니다. 그러나 응용 프로그램에서 데이터를 원래 형식으로 비교해야한다고 표시하면 전체 페이지가 주 메모리 버퍼 캐시로 읽히거나 쓰여질 때 변환됩니다. 이 두 가지 대안은 공간 및 보안을 성능에 맞게 교환 할 수있는 유연성을 제공합니다.
4.2 메모리 내 로깅 및 트랜잭션.
4.3 원격 로그.
4.4 데이터베이스 버퍼에 대한 응용 프로그램 참조.
4.5 복구 가능한 데이터베이스 생성 / 삭제.
4.6 적응성 동시성 제어.
버클리 DB는 더 거친 그레인, 교착 상태가없는 잠금을 수행하는 옵션을 제공합니다. 페이지 잠금은 데이터베이스에 대한 인터페이스에서 수행됩니다. 충돌하는 요청이 자동으로 대기열과 함께 여러 명의 독자 또는 단일 작성자가 언제든지 데이터베이스에서 활성화 될 수 있습니다. 응용 프로그램이 데이터를 읽고 쓸 수있는 커서가 있으면이 디자인이 복잡해집니다. 커서가 현재 읽기 용으로 사용되고 있지만 나중에 쓰는 데 사용되는 경우 특별한 예방 조치가 취해지지 않으면 시스템은 교착 상태가 발생하기 쉽습니다. 이 상황을 처리하기 위해 우리는 커서가 생성 될 때 응용 프로그램이 미래의 의도를 지정할 것을 요구합니다. 쓰려는 의도가있는 경우, 커서는 독자와 충돌하지 않고 다른 의도 쓰기 잠금 및 쓰기 잠금과 충돌하는 의도 쓰기 잠금이 부여됩니다. 최종 결과는 응용 프로그램이 임의의 시점에서 데이터베이스에 액세스 할 수있는 잠재적 인 쓰기 커서로 제한된다는 것입니다.
경합이 낮을 때 (잠재적으로 높은 처리량) 일반 페이지 수준 잠금은 최상의 전체 처리량을 제공합니다. 그러나 경쟁이 치열 해짐에 따라 교착 상태가 발생할 가능성도 있습니다. 크로스 오버 포인트에 따라 동시성은 낮지 만 교착 상태가없는 잠금 프로토콜로 전환하면 작업을 재 시도하지 않아도되므로 처리량이 높아집니다. 임베디드 데이터베이스 관리자의 운영 조건이 주어지면 시스템 자체가 높은 경합을 감지 할 때 자동으로 변경하는 것이 유용합니다.
4.7 적응 형 동기화.
5. 임베디드 시스템의 발자국.
오라클 라이트 3.0은 350KB ~ 750KB의 메모리와 약 2.5MB의 하드 디스크 공간이 필요하다고보고했다. 여기에는 ODBC 및 JDBC와 같은 인터페이스 용 드라이버가 포함됩니다. 반대로 Berkeley DB의 크기는 75KB에서 200KB 사이이며 ODBC 및 JDBC와 같은 중량 인터페이스를 사용하고 응용 프로그램 요구 사항에 따라 사용할 수있는 다양한 배포 크기를 제공합니다. 로우 엔드에서 간단한 단일 사용자 액세스 방법을 필요로하는 응용 프로그램은 확장 된 선형 해싱, B + 트리 또는 레코드 번호 기반 검색 중에서 선택할 수 있으며 75KB 공간 요구 사항 만 지불합니다. 세 가지 액세스 방법을 모두 요구하는 응용 프로그램은 110KB의 공간을 차지합니다. 하이 엔드에서는 완전 복구가 가능한 고성능 시스템이 4 메가 ​​바이트 미만의 메모리를 차지합니다. 이것은 토스터 오븐에 쉽게 통합 할 수있는 시스템입니다. 표 1은 전체 Berkeley DB 라이브러리의 모듈 별 분류를 보여줍니다. 여기에는 데이터베이스 페이지를 캐시하는 데 사용되는 메모리는 포함되지 않습니다.
6. 관련 연구.
Asilomar 보고서는 "기즈모"데이터베이스, 스마트 카드, 전화, 개인용 정보 단말기와 같은 소형 모바일 기기에 내장 된 작은 데이터베이스라는 데이터베이스 응용 프로그램의 새로운 클래스를 식별합니다. 이러한 데이터베이스는 자체 관리되고 안전하며 신뢰할 수 있어야합니다. 따라서 기즈모 데이터베이스는 데이터베이스 관리자 (DBA)가 없으며 사람이 설정할 수있는 매개 변수가없고 변화하는 조건에 적응할 수있는 플러그 앤 플레이 데이터 관리가 필요합니다. 좀 더 구체적으로, Asilomar의 저자들은 실제 DB 디자인, 논리적 DB 디자인, 자동 보고서 및 유틸리티를 정의하는 것을 포함하여 목표가자가 조정이라고 주장합니다. 현재까지이 문제를 받아 들인 연구자는 거의 없었으며, 연구 주제에 관한
임베디드 데이터베이스 관리에 대한 우리의 접근 방식은 Asilomar 저자가 설명한 것과 근본적으로 다릅니다. 우리는 용어를 채택하지만 기즈모 데이터베이스가 초기 배포 후에 자급 자족하는 데이터베이스를 지원하는 데 어려움을 겪고 있습니다. 따라서 우리는 수용 할 수있을뿐만 아니라 응용 프로그램 개발자가 초기 데이터베이스 설계 및 구성을 제어한다고 가정하는 것이 바람직합니다. 우리가 아는 한, 이 분야의 출판 된 연구는이 접근법을 다루지 않습니다.
연구 커뮤니티가이 분야에서 지침을 제공하지 않았기 때문에 임베디드 데이터베이스 관리 분야의 대부분의 업무가 상업적 벤더에 맡겨졌습니다. 이러한 공급 업체는 포함 또는 프로그래밍 방식 액세스 용으로 특별히 설계된 데이터베이스를 판매하는 회사와 주요 데이터베이스 공급 업체 (예 : Oracle, Informix, Sybase)의 두 가지 캠프로 나뉩니다.
임베디드 공급 업체는 모두 자동 관리의 필요성을 인정하지만 제품이 실제로이를 어떻게 달성하는지 정확하게 식별하지 못합니다. 주목할만한 예외는 Interbase이며, Sybase와 Microsoft의 SQL Server를 백서로 비교하면 유지 관리 용이성의 기능을 명시 적으로 설명합니다. Interbase는 로그 파일을 사용하지 않으므로 로그 교정, 검사 점 조정 또는 로그 관리와 관련된 다른 작업이 필요 없다고 주장합니다. 그러나 Interbase는 트랜잭션 정보 페이지를 사용하며 이러한 정보가 재사용되거나 재사용되는 방법은 분명하지 않습니다. 또한 로그가없는 시스템에서는 Haerder와 Reuter [4]가 정의한대로 FORCE 정책 (커밋시 디스크에 모든 페이지 작성)을 사용해야합니다. 이것은 디스크 기반 시스템에 심각한 성능 결과를 초래합니다. 이 백서에 설명 된 접근 방식은 로그를 사용하므로 로그 교정이 필요하지만 응용 프로그램이 안전하게 프로그래밍 방식으로 로그를 회수 할 수 있도록 후크를 제공합니다. Berkeley DB에는 검사 점이 필요하지만 검사 점 간격 조정의 목표는 복구 시간을 제한하는 것입니다. Berkeley DB의 검사 점 간격은 기록 된 로그 데이터의 양으로 표현 될 수 있으므로 조정이 필요하지 않습니다. 응용 프로그램 설계자는 목표 복구 시간을 설정하고 해당 간격에서 읽을 수있는 로그 데이터의 양을 선택하고 체크 포인트 간격을 적절히 지정합니다. 로드가 변경 되더라도 복구 시간은 길지 않습니다.
Interbase 및 Berkeley DB에서 수행 한 백업 접근 방식은 온라인 백업을 허용하지만 백업 중에 실행되는 트랜잭션에 미치는 영향이 서로 다르기 때문에 비슷합니다. Interbase는 트랜잭션 [6]으로 백업을 수행하므로 병행 쿼리는 잠재적으로 오랜 지연을 겪을 수 있습니다. Berkeley DB는 고유 한 운영 체제 시스템 유틸리티 및 백업 복구를 사용하므로 디스크 암에 대한 잠재적 인 경합 이외에 동시 작업에 방해가 없습니다.

임베디드 시스템의 절충
호환되지 않거나 지원되지 않는 브라우저를 사용하고있어 IEEE Xplore에서이 페이지를 표시 할 수 없습니다.
최상의 환경을 위해서는 아래의 링크를 사용하여 지원되는 최신 브라우저로 업그레이드하십시오. 브라우저를 업그레이드 할 수없는 경우 일반 텍스트 링크가 포함 된 기본 검색을 위해 임시 IEEE Xplore 사이트를 사용할 수 있습니다.
IEEE 계정.
구매 세부 사항.
프로필 정보.
US & amp; 캐나다 : +1 800 678 4333 전세계 : +1 732 981 0060.
비영리 조직인 IEEE는 인류의 이익을 위해 기술을 발전시키는 데 전념하는 세계 최대의 기술 전문 조직입니다.
&부; 저작권 2017 IEEE - 판권 소유. 이 웹 사이트의 사용은 이용 약관에 대한 귀하의 동의를 의미합니다.

임베디드 시스템의 절충
기 라트 알랭. "임베디드 시스템의 신뢰성, 소비 전력 및 실행 시간 간의 균형 조정". 토크 또는 프레젠테이션, 2012 년 8 월 14 일
자율적 인 중요한 실시간 임베디드 시스템 (예 : 위성)의 경우, 매우 높은 수준의 신뢰성을 보장하는 것이 전력 소비를 가능한 한 낮게 유지하는 것만 큼 중요합니다. 우리는 주어진 소프트웨어 어플리케이션 그래프와 주어진 멀티 프로세서 아키텍처 (동일하고 완벽하게 연결된)로부터 오프라인 스케줄링 휴리스틱을 제안합니다. 이 스케줄러는 길이 (실시간 시스템에서 중요 함), 신뢰성 (신뢰할 수있는 시스템에 필수적) 및 전력 소모 (자율 시스템에 필수적). TSH 라 불리는 우리의 tricriteria 스케줄링 휴리스틱은 작동 및 데이터 의존성의 능동 복제를 사용하여 신뢰성을 높이고 동적 전압 및 주파수 스케일링을 사용하여 전력 소비를 낮 춥니 다. 우리는 TSH가 실제로 어떻게 동작 하는지를 보여주기 위해 광범위한 시뮬레이션 결과를 제공합니다. 첫째, TSH를 단일 인스턴스에서 실행하여 전체 Pareto 프론트를 3D로 제공합니다. 두 번째로, 우리는 TSH와 ECS 발견 적 방법 (에너지 - 의식적 스케줄링)을 문헌과 비교한다. 셋째, TSH와 최적 혼합 선형 정수 프로그램을 비교합니다.
HTML 일반 텍스트 BibTeX.
Patricia Derler 님이 2012 년 8 월 15 일
자세한 내용은 간행물 FAQ 또는 chess eecs berkeley edu의 웹 마스터에게 문의하십시오.
공지 사항 :이 자료는 학술 및 기술 업무의 적시 보급을 위해 제공됩니다. 저작권 및 모든 권리는 저자 또는 다른 저작권 소유자가 보유합니다. 이 정보를 복사하는 모든 사람은 각 저자의 저작권에 의해 부과 된 조건 및 제약 조건을 준수해야합니다.