내 연락처 정보
우편메소피아@프로톤메일.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
임베디드 네트워크(Embedded Network)는 다양한 임베디드 시스템을 연결하여 서로 정보를 주고받고 자원을 공유하는데 사용되는 네트워크 시스템입니다. 임베디드 시스템은 거실의 홈 정보 네트워크, 산업 자동화 분야의 필드버스, 모바일 정보 장비와 같은 임베디드 시스템의 이동 통신 네트워크 등 상황에 따라 다른 연결 기술을 사용합니다. 임베디드 시스템을 연결하는 데 사용됩니다.
필드버스(Fieldbus)는 아날로그 계기제어 시스템, 중앙집중형 디지털 제어 시스템, 분산 제어 시스템에 이어 1980년대 중반에 개발된 컴퓨터 제어 기술로 오늘날 자동화 제어 분야의 기술 발전에 있어서 가장 핫한 분야이기도 하다. 산업 자동화 분야에서는 컴퓨터 근거리 통신망(Local Area Network)이라고도 합니다.
Fieldbus는 디지털 센서, 컨버터, 산업용 계측기 및 제어 액추에이터와 같은 현장 장치를 산업용 프로세스 제어 장치 및 현장 운영 스테이션과 상호 연결하는 네트워크입니다. 이는 완전한 디지털화, 분산화, 양방향 전송 및 다중 분기의 특성을 가지고 있으며 산업 제어 네트워크를 현장 수준으로 개발한 산물입니다.
필드버스(Fieldbus)는 생산관리 및 네트워크 구조의 최하위에 위치한 저대역폭 기반 제어 네트워크로, 기반 네트워크(인프라넷)라고도 불린다. 주로 생산 현장에서 측정 및 제어 장비 간의 양방향 직렬, 다중 노드 디지털 통신을 달성하는 데 사용됩니다.
FCS(Field Control System)는 필드버스를 이용하여 다양한 컨트롤러와 계측 장비를 연결하는 제어 시스템으로 제어 기능을 현장에 완전히 분산시켜 설치 비용과 유지 관리 비용을 절감합니다. 실제로 FCS는 개방적이고 상호 운용 가능하며 완전히 분산된 분산 제어 시스템입니다.
임베디드 현장 제어 시스템은 전용 마이크로프로세서를 기존 측정 및 제어 장비에 내장하여 디지털 컴퓨팅 및 디지털 통신 기능을 갖출 수 있게 해줍니다. 연선, 전력선 또는 광섬유를 버스로 사용하여 여러 측정 및 제어 장비를 네트워크에 연결합니다. 표준 통신 프로토콜에 따라 현장 및 현장 장비와 원격 모니터링 사이에 있는 여러 컴퓨터 측정 및 제어 장비를 연결합니다. .컴퓨터 간에 데이터 전송과 정보 교환이 실현되어 실제 요구에 적합한 다양한 자동 제어 시스템을 구성합니다. 즉, 필드버스 제어 시스템은 개별 분산 측정 및 제어 장치를 네트워크 노드로 전환하고 필드버스를 링크로 사용하여 이러한 분산 장치를 서로 통신하고 자동 제어 작업을 함께 완료할 수 있는 네트워크 시스템으로 만듭니다. 필드버스 기술의 도움으로 기존의 단일 분산 제어 장비는 서로 통신하고 협력하여 작동하는 전체가 되었습니다.
가정정보통신망은 가정 내 개인용 컴퓨터, 가전제품, 수도, 전기, 가스 계량기, 조명기기, 네트워크 장비, 보안장비 등을 연결하는 근거리 통신망이다. 주요 기능은 위에서 언급한 장치를 중앙에서 제어하고 이를 인터넷에 연결하여 네트워크 리소스와 서비스를 공유하는 것입니다. 또한, 홈 정보 네트워크는 집 전체, 심지어 커뮤니티 전체로 확장되어 스마트 주거 커뮤니티, 스마트 사회의 기반이 됩니다. 홈 정보 네트워크 시스템에서는 가전제품, 물, 전기, 가스 계량기, 조명 장비 등 모든 가정용 장치가 지능형입니다. 홈 게이트웨이를 통해 서로 통신하고 인터넷에 접속할 수 있습니다. 홈 정보 네트워크의 구현은 사람들에게 보다 안전하고, 편리하며, 편안한 가정 환경을 제공합니다. 예를 들어, 주인이 외출하면 문이 자동으로 닫히고 잠기며, 모니터링 시스템이 자동으로 켜지고, 집에 이상이 생기면 주인에게 자동으로 통보됩니다. 집안의 다양한 장치를 언제든지 제어할 수 있습니다. 언제 어디서나 장비 데이터를 자동으로 업로드할 수 있습니다.
가족정보네트워크는 다음과 같은 두 가지 기본적인 문제를 해결해야 합니다.
(1) 가전제품, 수도, 전기, 가스계량기, 조명기기 등을 서로 연결하는 방법.
(2) 이렇게 연결된 기기들 간의 상호 운용성을 구현하는 방법, 즉 홈 정보 네트워크의 기기들은 필요할 때 자동으로 서비스를 요청할 수 있고, 관련 기기들은 서비스를 제공하거나 요청을 수락하고 처리할 수 있습니다. 홈 정보 네트워크는 버스 유형, 스타 구조 등과 같은 다양한 토폴로지 구조를 채택할 수 있습니다. 홈 정보 네트워크는 여러 개의 제어 서브넷과 데이터 서브넷으로 더 나눌 수 있습니다. 제어 서브넷은 필드 버스와 유사하며 주로 제어 정보를 보내고 받는 데 사용됩니다. 데이터 서브넷은 대역폭 요구 사항이 더 높으며 여기에 연결된 장치는 많은 양의 데이터 정보를 전송해야 합니다.
최근에는 휴대전화 통신의 급속한 발전과 개인용 컴퓨터의 급속한 대중화로 인해 노트북 컴퓨터, 노트북 컴퓨터, 휴대형 컴퓨터 등 다양한 휴대용 컴퓨터에서 고정형 컴퓨터 간의 데이터 통신이 급격히 증가하고 있다. 더 이상 요구 사항을 충족하지 않습니다. 사람들은 언제 어디서나 데이터 정보를 전송하고 교환하기를 원하면서 데이터 통신 전송 매체가 유선에서 무선으로 확대되기 시작했고, 무선 모바일 데이터 통신이 등장하게 되었습니다. 무선 데이터 통신망은 전파를 통해 데이터를 전송하는 네트워크 시스템이다. 유선 데이터 통신을 기반으로 개발되었으며, 모바일 상태에서도 데이터 통신을 구현할 수 있습니다.무선 데이터 통신망을 통해 스마트폰, PDA,
노트북 컴퓨터는 서로 데이터 정보를 주고 받으며 인터넷에 접속할 수 있습니다. 무선 데이터 통신망은 근거리 무선망과 무선인터넷으로 구분된다. 단거리 무선 네트워크에는 주로 802.11, Bluetooth, IrDA 및 HomeRF가 포함됩니다. 무선 인터넷 또는 모바일 인터넷은 주로 두 가지 무선 연결 기술을 사용합니다. 하나는 GSM, GPRS, CDPD(Cellular Digital Packet Data) 등과 같은 모바일 무선 액세스 기술이고, 다른 하나는 마이크로파, 확산 스펙트럼 통신을 포함한 고정 무선 액세스 기술입니다. , 위성 및 무선 광전송 등
인터넷과 임베디드 기술의 급속한 발전으로 인해 웹 비디오폰, 셋톱박스, 정보가전, 기타 임베디드 시스템 제품 등 정보가전이 인터넷에 연결되어 편리함을 공유할 필요성이 점점 더 많아지고 있습니다. 인터넷이 제공하는 유비쿼터스 정보 자원과 서비스, 즉 임베디드 인터넷 기술. 임베디드 인터넷 기술은 지능형 교통, 가사 시스템, 홈 오토메이션, 산업 자동화, POS 및 전자 상거래 분야에서 광범위한 응용 가능성을 가지고 있습니다.
1.임베디드 인터넷 접속 방식
임베디드 장치에는 TCP/IP 프로토콜 스택과 관련 소프트웨어가 통합되어 있으며, 이러한 장치는 인터넷에서 노드로 사용될 수 있고 IP 주소가 할당되며 인터넷과 직접 상호 연결될 수 있습니다. 이 액세스 방법의 특징은 다음과 같습니다.
2.임베디드 TCP/IP 프로토콜 스택
임베디드 TCP/IP 프로토콜 스택이 완성하는 기능은 전체 TCP/IP 프로토콜 스택과 동일합니다. 그러나 임베디드 시스템의 자원 제한으로 인해 임베디드 프로토콜 스택의 일부 표시기와 인터페이스가 다를 수 있습니다. 프로토콜 스택.
(1) 임베디드 프로토콜 스택의 호출 인터페이스는 일반 프로토콜 스택의 호출 인터페이스와 다릅니다. 일반 프로토콜 스택의 소켓 인터페이스는 표준이며 응용 프로그램 소프트웨어는 호환성이 좋습니다. 그러나 표준화된 인터페이스를 구현하는 데 드는 코드 오버헤드, 처리 및 저장 오버헤드가 엄청납니다. 따라서 대부분의 제조업체는 표준 프로토콜 스택 인터페이스를 임베디드 시스템에 이식할 때 다양한 수준의 수정 및 단순화를 수행했으며, 그들이 제공하는 API는 일반 프로토콜 스택의 API와 완전히 동일해야 합니다. .
(2) 임베디드 프로토콜 스택의 맞춤성. 대부분의 임베디드 프로토콜 스택은 모듈식입니다. 메모리 공간이 제한되어 있으면 필요할 때 동적으로 설치할 수 있으며 인터페이스 전달 및 전체 인터넷 서비스 도구 세트와 같은 임베디드 시스템에 필수적이지 않은 여러 부분이 생략됩니다.
(3) 임베디드 프로토콜 스택의 플랫폼 호환성. 일반적으로 프로토콜 스택은 운영 체제와 긴밀하게 통합되며 대부분의 프로토콜 스택은 운영 체제 커널에서 구현됩니다. 프로토콜 스택의 구현은 운영 체제에서 제공하는 서비스에 따라 다르며 이식성이 좋지 않습니다. 임베디드 프로토콜 스택의 구현은 일반적으로 운영 체제에 대한 의존성이 거의 없으며 이식이 쉽습니다. 많은 상용 임베디드 프로토콜 스택은 여러 운영 체제 플랫폼을 지원합니다.
(4) 임베디드 프로토콜 스택의 효율성이 높습니다. 임베디드 프로토콜 스택의 구현은 일반적으로 더 적은 공간을 차지하고 더 작은 데이터 메모리가 필요하며 코드 효율적이므로 프로세서 성능 요구 사항이 줄어듭니다.
임베디드 기술의 발전과 함께 임베디드 데이터베이스도 점차 응용 쪽으로 옮겨가고 있습니다. 본질적으로 임베디드 데이터베이스는 일반 데이터베이스를 기반으로 개발되어 다양한 임베디드 디바이스나 모바일 디바이스에서 구동되는데, 이는 임베디드 시스템 자체의 응용 환경에 의해 제약을 받기 때문에 임베디드 시스템에서 그 우수성을 보여주는데, 임베디드 데이터베이스는 일반 데이터베이스와는 다른 특성을 가지고 있다. .
일반적으로 임베디드 데이터베이스 관리 시스템은 임베디드 장치에 사용되는 데이터베이스 관리 시스템입니다. 임베디드 데이터베이스 관리 시스템의 대부분은 휴대용 컴퓨터, PDA, 차량 탑재 장치 및 기타 이동 통신 장치와 같은 모바일 정보 장치이므로 고정 위치 임베디드 장치는 거의 사용되지 않습니다. 따라서 임베디드 데이터베이스를 모바일 데이터베이스 또는 모바일이라고도 합니다. 데이터베이스. 내장형 모바일 데이터베이스.주요 기능은 모바일 컴퓨팅 환경의 데이터 관리 문제를 해결하는 것입니다. 모바일 데이터베이스는 모바일 컴퓨팅 환경의 중요한 부분입니다.
분산 데이터베이스.
임베디드 시스템에 데이터베이스 기술을 도입하는 것은 주로 임베디드 운영 체제 또는 베어 메탈에서 직접 정보 관리 애플리케이션을 개발할 때의 다음과 같은 단점 때문입니다.
(1) 모든 애플리케이션에는 반복적인 데이터 관리 작업이 필요하므로 개발의 어려움과 비용이 증가합니다.
(2) 애플리케이션 간의 데이터 공유가 좋지 않습니다.
(3) 응용소프트웨어는 독립성, 휴대성, 재사용성이 낮다.
데이터베이스 관리 시스템을 임베디드 시스템에 도입하면 위와 같은 문제를 상당 부분 해결할 수 있으며, 응용 시스템의 개발 효율성과 이식성을 향상시킬 수 있습니다.
임베디드 데이터베이스 시스템은 임베디드 데이터베이스 관리 시스템을 포함하고 모바일 통신 장치, 워크스테이션 또는 데스크탑 컴퓨터 및 데이터 서버를 포괄하는 포괄적인 시스템입니다. 이러한 시스템의 특성과 시스템의 사용 환경은 임베디드 데이터베이스 관리 시스템에 큰 영향을 미칩니다. .더 큰 영향은 내장된 데이터베이스 관리 시스템의 구조에 직접적인 영향을 미칩니다. 사용환경의 특징은 간단히 다음과 같이 요약할 수 있습니다.
(1) 장치는 언제든지 이동 가능합니다. 내장된 데이터베이스는 주로 모바일 정보 장치에 사용됩니다. 장치의 위치는 사용자와 함께 이동합니다.
(2) 네트워크 연결이 자주 끊어지고, 사용 중에 모바일 기기나 모바일 단말기의 위치가 자주 바뀌는 경우도 있으며, 사용 방식, 전원 공급, 무선 통신, 네트워크 상태 등의 요인에 의해서도 영향을 받습니다. 따라서 네트워크 연결은 일반적으로 지속적으로 유지되지 않고, 능동적 또는 수동적으로 연결이 끊어지고 간헐적으로 연결되는 경우가 많습니다.
(3) 모바일 정보기기의 위치는 빈번하게 변경되므로 네트워크 상황이 다양하므로 모바일 정보기기와 데이터 서버가 서로 다른 시간에 서로 다른 네트워크 시스템을 통해 연결될 수 있습니다. 이러한 네트워크는 네트워크 대역폭, 통신 비용, 네트워크 지연, 서비스 품질 등이 다를 수 있습니다.
(4) 비대칭 통신 기능 모바일 장치의 리소스 제약으로 인해 모바일 장치와 서버 간의 네트워크 통신 기능이 비대칭입니다. 모바일 장치의 전송 기능은 매우 제한되어 있으므로 데이터 서버에서 모바일 장치로의 다운링크 통신 대역폭과 모바일 장치에서 데이터 서버로의 업링크 대역폭이 매우 다릅니다.
완전한 임베디드 데이터베이스 관리 시스템은 그림 12-6과 같이 기본 데이터베이스 관리 시스템, 동기화 서버, 임베디드 데이터베이스 관리 시스템, 연결 네트워크 및 기타 하위 시스템을 포함한 여러 하위 시스템으로 구성됩니다.
(1) 내장형 데이터베이스 관리 시스템. 내장형 데이터베이스 관리 시스템은 기능적으로 독립적인 단일 사용자 데이터베이스 관리 시스템입니다. 동기화 서버 및 메인 데이터베이스 관리 시스템과 독립적으로 실행되어 임베디드 시스템의 데이터를 관리할 수도 있고, 동기화 서버를 통해 메인 서버에 연결하여 메인 데이터베이스 내에서 운영할 수도 있습니다. 다양한 방법으로 데이터 동기화.
(2) 동기화 서버. 동기화 서버는 내장 데이터베이스와 메인 데이터베이스 간의 연결 허브로서 내장 데이터베이스와 메인 데이터베이스의 데이터 일관성을 보장합니다.
(3) 데이터 서버. 데이터 서버의 메인 데이터베이스 및 데이터베이스 관리 시스템은 Oracle, Sybase 등 대규모 범용 데이터베이스 시스템을 사용할 수 있습니다.
(4) 네트워크에 연결합니다. 기본 데이터베이스 서버와 동기화 서버는 일반적으로 고대역폭, 저지연 고정 네트워크를 통해 연결됩니다. 모바일 장치와 동기화 서버 간의 연결은 장치의 특정 조건에 따라 무선 LAN, 적외선 연결, 범용 직렬 회선 또는 공용 네트워크일 수 있습니다.
1.애플리케이션에 내장된 모바일 데이터베이스의 핵심
실제 애플리케이션에서 임베디드 모바일 데이터베이스는 데이터 일관성(복제), 효율적인 트랜잭션 처리 및 데이터 보안과 같은 문제를 해결해야 합니다.
(1) 데이터 일관성. 내장된 모바일 데이터베이스의 주목할만한 특징은 모바일 데이터 단말과 동기화 서버 간의 연결이 약한 연결, 즉 낮은 대역폭, 긴 지연, 불안정하고 빈번한 연결 끊김이라는 점입니다. 취약한 환경에서 데이터베이스에 대한 사용자 작업을 지원하기 위해 이제 사용자가 로컬 캐시에서 데이터 복사본을 작업할 수 있도록 하는 낙관적 복제 방법(Optimistic 복제 또는 지연 복제)이 일반적으로 사용됩니다. 네트워크가 재연결된 후 데이터베이스 서버나 다른 모바일 데이터 단말과 데이터 수정 정보를 교환하고, 충돌 감지 및 조정을 통해 데이터 일관성을 복원합니다.
(2) 효율적인 거래 처리. 모바일 거래는 빈번하고 예측 가능한 연결 끊김이 있는 모바일 환경에서 수행됩니다. 활성 거래의 원활한 완료를 보장하기 위해서는 새로운 거래 관리 전략과 알고리즘을 설계하고 구현해야 합니다. 네트워크 연결 상태에 따라 거래 처리 우선순위를 결정하고, 네트워크 연결 속도가 빠른 거래 요청을 먼저 처리합니다.
작업 시간을 기준으로 트랜잭션이 마이그레이션되는지 여부를 결정합니다. 즉, 모든 장기 트랜잭션 작업이 실행을 위해 서버로 마이그레이션되며 트랜잭션 업로드 여부를 결정하기 위해 네트워크가 항상 원활한지 확인할 필요가 없습니다. 데이터 크기에 따라 데이터 복사가 실행된 후 다운로드됩니다. 트랜잭션 처리 중 네트워크 연결 해제 처리 시 사용자 위치 속성을 실시간으로 업데이트할 때 서버 검색 메커니즘을 사용할지 여부. 거래 이동(예: 위치 관련 쿼리)
(3) 데이터 보안. 많은 응용 분야의 임베디드 장치는 시스템의 데이터 관리 또는 처리를 위한 핵심 장치이므로 임베디드 장치의 데이터베이스 시스템은 액세스 권한을 더욱 엄격하게 제어합니다. 동시에 많은 임베디드 장치는 높은 이동성, 휴대성 및 고정되지 않은 작업 환경을 가지고 있어 잠재적인 안전하지 않은 요소도 가져옵니다. 또한 일부 데이터는 개인정보 보호 수준이 높기 때문에 충돌, 자기장 간섭, 분실, 도난 방지 측면에서 개인 데이터의 보안이 완전히 보장되어야 합니다. 데이터 보안을 보장하는 주요 조치는 불법 단말기의 부정 접속을 방지하기 위한 모바일 단말기 인증, 데이터 정보 유출을 방지하기 위한 무선 통신 암호화, 모바일 단말기의 물리적 손실을 방지하기 위한 다운로드된 데이터 복사본의 저장입니다.
2.모바일 데이터베이스 관리 시스템의 특징
모바일 DBMS의 컴퓨팅 환경은 기존의 분산 DBMS를 확장한 것으로 클라이언트와 고정 서버 노드가 동적으로 연결되는 분산 시스템이라고 볼 수 있다. 따라서 모바일 컴퓨팅 환경의 데이터베이스 관리 시스템은 동적 분산 데이터베이스 관리 시스템이다. 임베디드 모바일 데이터베이스 관리 시스템은 모바일 컴퓨팅 환경의 임베디드 운영 체제에 적용되므로 고유한 특성과 기능적 요구 사항을 가지고 있습니다.
(1) 마이크로커널 구조는 임베디드 기능의 구현을 용이하게 합니다. 임베디드 디바이스의 제한된 자원을 고려할 때 임베디드 모바일 DBMS는 소형화 기술을 사용하여 구현되어야 하며 임베디드 애플리케이션의 요구 사항을 충족하도록 시스템 구조를 압축해야 합니다.
(2) 표준 SQL을 지원합니다. 임베디드 모바일 DBMS는 표준 SQL을 지원해야 합니다. SQL92 표준의 하위 집합을 지원하고 데이터 쿼리(조인 쿼리, 하위 쿼리, 정렬, 그룹화 등), 여러 표준 SQL 문 삽입, 업데이트, 삭제를 지원하여 임베디드 애플리케이션 개발 요구 사항을 완벽하게 충족합니다.
(3) 거래 관리 기능. 임베디드 모바일 DBMS는 트랜잭션 처리 기능을 갖추고 트랜잭션 무결성, 원자성 및 기타 특성을 자동으로 유지해야 하며 엔터티 무결성 및 참조 무결성을 지원해야 합니다.
(4) 완전한 데이터 동기화 메커니즘. 데이터 동기화는 내장형 데이터베이스의 가장 중요한 기능입니다. 데이터 복제를 통해 내장 데이터베이스 또는 메인 데이터베이스의 변경 사항을 서로 적용하여 데이터 일관성을 보장할 수 있습니다. 임베디드 모바일 데이터베이스 관리 시스템의 데이터 동기화 메커니즘은 다음과 같은 특징을 가져야 합니다.
(5) 다중 연결 프로토콜을 지원합니다. 임베디드 모바일 DBMS는 다양한 통신 연결 프로토콜을 지원해야 합니다. 임베디드 장치 및 데이터베이스 서버에 대한 연결은 직렬 통신, TCP/IP, 적외선 전송, Bluetooth 등 다양한 연결 방법을 통해 이루어질 수 있습니다.
(6) 내장된 데이터베이스 관리 기능을 완료합니다. 내장형 모바일 DBMS는 기본적으로 내장형 데이터베이스 관리에 수동 개입이 필요하지 않고 데이터 백업 및 복구 기능을 제공하여 사용자 데이터의 안전성과 신뢰성을 보장할 수 있는 자동 복구 기능을 갖추고 있어야 합니다.
(7) 플랫폼 독립성 및 다중 임베디드 운영 체제 지원. 임베디드 모바일 DBMS는 Windows CE, Palm OS 등 현재 널리 사용되는 다양한 임베디드 운영 체제를 지원할 수 있어야 임베디드 모바일 데이터베이스 관리 시스템이 모바일 단말에 의해 제한되지 않습니다.
(8) 제로 관리 기능. 내장형 데이터베이스에는 자동 복구 기능이 있어 수동 개입 없이 내장형 데이터베이스를 관리할 수 있으며 데이터 백업 및 동기화 기능을 제공합니다.
또한, 이상적인 상태는 사용자가 단 하나의 모바일 단말기(예: 휴대폰)를 사용하여 관련된 모든 모바일 데이터베이스에 대한 데이터 작업 및 관리를 수행할 수 있다는 것입니다. 이를 위해서는 프런트엔드 시스템이 보편적이어야 하고, 모바일 데이터베이스의 인터페이스가 통일되고 표준화된 표준을 갖춰야 합니다. 프런트 엔드 관리 시스템은 데이터 처리 중에 통합 트랜잭션 처리 명령을 자동으로 생성하고 이를 현재 연결된 데이터 서버에 제출하여 실행합니다. 이는 임베디드 모바일 데이터베이스 관리 시스템의 다양성을 효과적으로 향상시키고 임베디드 모바일 데이터베이스의 응용 가능성을 확장합니다.
즉, 임베디드 모바일 데이터베이스 관리 시스템에서는 연결 해제 작업 지원, 지역 간 장기 트랜잭션 지원, 위치 관련 쿼리 지원 등 기존 컴퓨팅 환경에서 고려할 필요가 없는 많은 문제를 고려해야 합니다. , 제한된 리소스 활용도 및 시스템 효율성 향상을 위한 특별 고려 사항 및 고려 사항입니다. 위와 같은 문제를 효과적으로 해결하기 위해 복제 및 캐싱 기술, 모바일 트랜잭션 처리, 데이터 브로드캐스트 기술, 모바일 질의 처리 및 질의 최적화, 위치 관련 데이터 처리 및 질의 기술, 모바일 정보 출판 기술, 모바일 에이전트 등의 기술이 필요합니다. 기술은 여전히 개발 중입니다. 개발과 개선을 통해 임베디드 모바일 데이터베이스 관리 시스템의 개발이 더욱 촉진될 것입니다.
간단히 말해서, 실시간 시스템은 외부 이벤트에 적시에 대응할 수 있는 시스템으로 볼 수 있습니다. 이러한 종류의 시스템의 가장 중요한 특징은 적시성, 즉 실시간성입니다. 실시간 시스템의 정확성은 시스템 계산의 논리적 결과뿐만 아니라 이러한 결과가 생성되는 시간에도 좌우됩니다.
현재 대부분의 실시간 시스템은 임베디드이며 실제 실행되는 임베디드 시스템에도 실시간 요구 사항이 있으므로 다양한 유형의 임베디드 운영 체제 중에서 실시간 임베디드 운영 체제가 가장 대표적인 특징을 갖고 있습니다. 따라서 본 절에서는 주로 실시간 임베디드 운영체제의 특징과 개념을 중심으로 임베디드 운영체제의 기본 개념과 특징, 기본 아키텍처, 커널 등을 소개한다. 서비스, 커널 개체, 커널 서비스 등이 있습니다.
현실 세계에서는 모든 임베디드 시스템이 실시간 특성을 갖는 것은 아니며, 모든 실시간 시스템이 반드시 임베디드되는 것은 아닙니다. 그러나 이 두 시스템은 상호 배타적이지 않으며, 두 시스템의 특성을 모두 갖고 있는 시스템을 실시간 임베디드 시스템이라고 합니다. 이들 사이의 관계는 그림 12-7에 나와 있습니다.
(1) 올바른 논리(또는 기능)는 시스템이 외부 이벤트를 처리할 때 올바른 결과를 생성할 수 있음을 의미합니다.
(2) 정확한 시간이란 시스템의 외부 이벤트 처리가 미리 정해진 기간 내에 완료되어야 함을 의미합니다.
(3) 마감일 또는 시간 제한, 마감일은 시스템이 외부 이벤트를 처리해야 하는 최신 시간 제한을 의미합니다. 이 제한을 놓치면 심각한 결과가 발생할 수 있습니다. 일반적으로 계산은 제한 시간에 도달하기 전에 완료되어야 합니다.
(4) 실시간 시스템은 정확한 기능과 정확한 시간을 모두 만족시키는 시스템을 말합니다. 즉, 실시간 시스템은 시간이 제한되어 있고 마감일에 따라 운영됩니다. 그러나 일부 시스템에서는 기능적 정확성을 보장하기 위해 타이밍 정확성이 희생될 수 있습니다.
실시간 시스템 분할의 경우 실시간 시스템은 일반적으로 다음과 같이 나눌 수 있습니다.
(1) 강력한 실시간 시스템, 시스템의 응답 시간은 일반적으로 밀리초 또는 마이크로초 수준으로 매우 짧습니다.
(2) 일반적인 실시간 시스템의 경우 시스템 응답 시간은 일반적으로 두 번째 수준의 강력한 실시간 시스템보다 낮습니다.
(3) 약한 실시간 시스템의 경우 시스템 응답 시간이 더 길어질 수 있으며 시스템 부하의 심각도에 따라 변경될 수도 있습니다.
실시간 시스템은 마감 기한 준수 또는 결과의 심각성에 따라 소프트 실시간 시스템과 하드 실시간 시스템으로 나눌 수 있습니다.
(1) 하드 실시간 시스템은 유연성이 시간 제한이 0에 가까운 실시간 시스템을 의미합니다.제한 시간을 준수해야 합니다.
그렇지 않으면 재앙적인 결과가 발생할 것이며, 제한 시간 이후에 얻은 처리 결과는 0 수준의 쓸모가 없거나 매우 평가절하될 것입니다.
(2) 소프트 실시간 시스템은 시간 제한 요구 사항을 충족해야 하지만 어느 정도 유연성을 갖춘 실시간 시스템을 의미합니다. 마감일에는 다양한 허용 수준, 평균 마감일 또는 응답 시간의 수용 정도가 다양한 통계 분포가 포함될 수 있습니다. 소프트 실시간 시스템에서는 마감 기한을 놓쳐도 일반적으로 시스템 오류와 같은 심각한 결과로 이어지지 않습니다. 표 12-2는 소프트 실시간 시스템과 하드 실시간 시스템을 비교한 것입니다.
이에 비해 마감일을 놓친 것은 소프트 실시간 시스템의 작동에 결정적인 영향을 미치지 않으므로 소프트 실시간 시스템은 놓친 마감일을 보류할 수 있는지 여부를 예측할 필요가 없음을 알 수 있습니다. 대조적으로, 소프트 실시간 시스템은 놓친 기한을 감지한 후 복구 프로세스를 시작할 수 있습니다.
실시간 시스템에서는 작업의 시작 시간이 마감 시간이나 완료 시간만큼 중요합니다. 작업에는 CPU, 메모리 등 필요한 리소스가 부족하기 때문에 작업 실행 시작을 방해하고 누락으로 직결될 수 있습니다. 작업 완료 기한이 지정되어 기한 문제가 리소스 예약 문제로 발전합니다.
이는 스케줄링 알고리즘과 작업 설계에 중요한 영향을 미칩니다.
임베디드 운영체제(Embedded Operating System)란 임베디드 컴퓨터 시스템에서 실행되어 임베디드 애플리케이션을 지원하는 운영체제를 말하며, 임베디드 시스템에서 하드웨어와 소프트웨어 자원을 제어, 관리하고 시스템 서비스를 제공하는 데 사용되는 소프트웨어의 집합체를 말합니다. 임베디드 운영체제는 임베디드 소프트웨어의 중요한 부분입니다. 그 출현으로 임베디드 소프트웨어 개발의 효율성이 향상되고, 응용 소프트웨어의 이식성이 향상되었으며, 임베디드 시스템 개발이 효과적으로 촉진되었습니다.
1.임베디드 운영체제의 특징
범용 운영체제와 비교하여 임베디드 운영체제는 주로 다음과 같은 특징을 가지고 있습니다.
(1) 소형화: 임베디드 운영체제의 실행 플랫폼은 범용 컴퓨터가 아닌 임베디드 컴퓨터 시스템이다. 이러한 유형의 시스템은 일반적으로 대용량 메모리가 없고 외부 메모리도 거의 없습니다. 따라서 임베디드 운영체제는 시스템 리소스를 최대한 적게 차지하도록 컴팩트하게 만들어야 합니다. 임베디드 시스템의 소프트웨어는 일반적으로 시스템의 실행 속도와 신뢰성을 향상시키기 위해 디스크와 같은 캐리어에 저장되지 않고 메모리 칩에 고체화된다.
(2) 높은 코드 품질: 대부분의 응용 프로그램에서 저장 공간은 여전히 귀중한 자원이므로 프로그램 코드의 품질이 높고 코드가 최대한 간소화되어야 합니다.
(3) 전문화: 임베디드 시스템을 위한 다양한 하드웨어 플랫폼이 있으며, 각 프로세서는 다양한 응용 분야에 맞게 특별히 설계되었습니다. 따라서 임베디드 운영 체제는 적응성과 이식성이 좋아야 하며 다양한 개발 플랫폼도 지원해야 합니다.
(4) 강력한 실시간 성능: 임베디드 시스템은 프로세스 제어, 데이터 수집, 통신, 멀티미디어 정보 처리 및 기타 실시간 응답이 필요한 상황에 널리 사용됩니다. 따라서 실시간 성능은 임베디드 운영 체제의 또 다른 특징이 되었습니다. .
(5) 절단 가능 및 구성 가능: 응용 프로그램이 다양하려면 임베디드 운영 체제가 강력한 적응성을 갖고 소형화 및 전문화 요구 사항에 적응하기 위해 응용 프로그램의 특성 및 특정 요구 사항에 따라 유연하게 구성하고 합리적으로 절단할 수 있어야 합니다.
2.임베디드 운영체제의 분류
임베디드 운영체제에는 다양한 유형이 있으며 다양한 관점에서 분류할 수 있습니다. 임베디드 운영체제의 취득 형태에 따라 상업용 유형과 무료 유형의 두 가지 범주로 나눌 수 있습니다.
(1) 상업용 유형. 상업용 임베디드 운영 체제는 일반적으로 안정적이고 신뢰할 수 있는 기능, 완벽한 기술 지원, 완벽한 개발 도구 및 애프터 서비스를 갖추고 있습니다. WindRiver의 VxWorks, pSOS, Palm의 Palm OS 등이 있습니다. 그러나 비용이 많이 들고 사용자는 일반적으로 시스템의 소스 코드를 얻을 수 없습니다.
(2) 자유형. 무료 임베디드 운영 체제의 장점은 가격에 있습니다. 또한 응용 시스템 개발자는 시스템 소스 코드를 얻을 수 있어 개발이 편리합니다. 그러나 무료 운영 체제는 기능이 단순하고 기술 지원이 열악하며 시스템 안정성이 좋지 않습니다. 대표적인 대표적인 시스템으로는 임베디드 리눅스, uC/OS 등이 있습니다. 임베디드 운영 체제의 실시간 특성으로 인해 실시간 임베디드 운영 체제와 비실시간 임베디드 운영 체제라는 두 가지 범주로 나눌 수 있습니다.
(1) 실시간 임베디드 OS(RTEOS). 실시간 임베디드 운영 체제는 실시간 시스템 작업을 지원하며, 주요 작업은 외부 이벤트에 대한 실시간 응답 시간 제한을 충족하기 위해 사용 가능한 모든 리소스를 예약하는 것입니다. 둘째, 시스템 효율성을 향상시키는 데 중점을 둡니다. 실시간 임베디드 운영 체제는 주로 제어, 통신 및 기타 분야에서 사용됩니다. 현재 대부분의 상용 임베디드 운영 체제는 실시간 운영 체제입니다.
(2) 비실시간 임베디드 운영 체제. 이러한 유형의 운영 체제는 단일 작업의 응답 시간에 특별한 주의를 기울이지 않습니다. 평균 성능, 시스템 효율성 및 리소스 활용도가 일반적으로 높으며 엄격한 실시간 요구 사항이 없는 가전 제품에 적합합니다. 개인용 디지털 단말기, 셋톱박스 등과 같은
전반적으로 임베디드 시스템의 실시간 성능은 하드웨어, 실시간 운영 체제 및 애플리케이션에 의해 결정됩니다. 그중에서도 임베디드 실시간 운영 체제 코어의 성능이 중요한 역할을 합니다. 일반적으로 실시간 임베디드 운영 체제에는 실시간 커널 기반 RTEOS와 범용 RTEOS의 두 가지 유형이 있습니다.
실시간 커널형 RTEOS: 이 유형의 운영 체제인 드라이버는 전통적으로 커널에 내장되어 있으며 애플리케이션과 미들웨어는 표준 애플리케이션 프로그래밍 인터페이스(API, 애플리케이션 프로그래밍 인터페이스)에서 구현됩니다.
실시간 범용 RTEOS: 이 유형의 운영 체제에서는 드라이버가 커널에 깊이 내장되어 있지 않지만 커널 위에 구현되며 몇 가지 필수 드라이버만 포함되어 있으며 애플리케이션과 미들웨어를 직접 구현할 수 있습니다. 표준 API로 구현하지 않아도 됩니다. 이들의 차이점은 그림 12-8에 나와 있습니다.
실시간 임베디드 운영 체제와 범용 운영 체제 간에는 많은 기능적 유사점이 있습니다. 예를 들어 둘 다 멀티태스킹을 지원하고 소프트웨어 및 하드웨어의 리소스 관리를 지원하며 둘 다 애플리케이션을 위한 기본 운영 체제 서비스를 제공합니다.
1.임베디드 실시간 운영체제의 주요 특징
범용 운영체제에 비해 실시간 임베디드 운영체제는 기능면에서 많은 특징을 가지고 있습니다. 범용 운영체제와는 다른 실시간 임베디드 운영체제 고유의 주요 기능은 다음과 같습니다.
2.임베디드 실시간 운영체제의 실시간 성능 지표 실시간 운영체제 설계의 성능을 평가할 때 시간 성능 지표
지표는 가장 중요한 성과 지표로 일반적으로 사용되는 시간 성과 지표는 다음과 같습니다.
(1) 작업 전환 시간: 작업 전환을 수행할 때 작업 컨텍스트를 저장 및 복원하고 실행할 다음 작업을 선택하는 데 소요되는 시간을 포함하여 실행 중인 작업에서 다른 준비된 작업으로 CPU 제어권을 전환하는 데 필요한 시간을 의미합니다. 시간, 이 표시기는 레지스터 수 및 마이크로프로세서의 시스템 구조와 관련이 있습니다. 동일한 운영 체제가 다른 마이크로프로세서에서 실행될 때 다른 시간이 걸릴 수 있습니다. 태스크 전환 시간에 해당하는 타이밍 다이어그램은 그림 12-9에 나와 있습니다.
(2) 인터럽트 처리와 관련된 시간 표시기, 해당 인터럽트 타이밍 다이어그램은 그림 12-10에 나와 있습니다.
인터럽트 지연 시간은 인터럽트 발생부터 시스템이 인터럽트를 학습하는 데 걸리는 시간을 의미하며, 주로 시스템의 최대 오프-인터럽트 시간에 영향을 받습니다.
중단 시간이 길수록 중단 지연도 길어집니다.
특정 응용 프로그램에 의해 결정되는 인터럽트 처리 실행 시간.
인터럽트 응답 시간은 인터럽트 발생부터 사용자 인터럽트 서비스 루틴 실행 시작까지의 시간을 의미합니다.
인터럽트 복구 시간은 사용자의 인터럽트 서비스 루틴이 종료되고 인터럽트된 코드로 복귀하는 사이의 시간을 나타냅니다.
최대 인터럽트 끄기 시간에는 두 가지 측면이 포함됩니다. 하나는 커널의 최대 인터럽트 끄기 시간입니다. 즉, 임계 섹션 코드를 실행할 때 커널이 인터럽트를 끄는 것입니다. 다른 하나는 응용 프로그램의 인터럽트 끄기 시간과 최대 인터럽트 끄기입니다. 시간은 이 두 인터럽트 오프 시간의 최대값입니다. 태스크 응답 시간은 태스크에 해당하는 인터럽트가 생성된 시점부터 태스크가 실제로 실행되기 시작할 때까지의 시간을 나타냅니다.
선점형 스케줄링의 경우 작업 전환 및 새 작업 컨텍스트 복원 시간에 인터럽트 복구 시간도 추가됩니다.
사이.
(3) 시스템 응답 시간: 시스템이 처리 요청을 발행한 시점부터 시스템이 응답할 때까지의 시간, 즉 스케줄링 지연을 의미하며 이 시간의 크기는 주로 커널 작업 스케줄링 알고리즘에 의해 결정됩니다. 이를 요약하면 선점형 실시간 커널의 대표적인 성능지수 계산 방식을 표 12-3에 나타내었다.
불완전한 통계에 따르면 지금까지 전 세계에 존재하는 임베디드 운영 체제의 총 개수는 수백 개에 이릅니다. 가장 일반적으로 사용되는 운영 체제는 12가지가 넘습니다. 이러한 운영 체제는 해당 응용 분야에서 높은 인기와 대규모 사용자 기반을 가지고 있습니다. 표 12-4에서는 비교를 위해 업계에서 널리 사용되는 일부 임베디드 운영 체제를 선택합니다.
임베디드 시스템 설계의 주요 임무는 시스템 기능을 정의하고, 시스템 아키텍처를 결정하고, 기능을 시스템 구현 아키텍처에 매핑하는 것입니다. 여기서 시스템 아키텍처에는 소프트웨어 시스템 아키텍처와 하드웨어 시스템 아키텍처가 모두 포함됩니다. 아키텍처는 다양한 물리적 구현에 매핑될 수 있으며, 각각은 특정 설계 기준을 충족하고 다른 것을 최적화하는 동시에 서로 다른 장단점을 나타냅니다.
임베디드 시스템의 설계 방법은 일반적인 하드웨어 설계 및 소프트웨어 개발 방법과 다르며, 하드웨어와 소프트웨어 공동 설계 방법을 채택합니다. 개발 프로세스에는 소프트웨어 분야의 지식뿐만 아니라 하드웨어에 대한 포괄적인 지식도 포함됩니다. 분야, 심지어 기계 등 지식의 측면도 포함됩니다. 설계자는 설계된 시스템을 최적화하기 위해 해당 분야의 다양한 기술을 숙지하고 자유롭게 사용할 수 있어야 합니다.
임베디드 시스템 응용 소프트웨어의 설계 솔루션은 응용 분야에 따라 다르지만, 임베디드 시스템의 분석 및 설계 방법도 소프트웨어 엔지니어링의 일반적인 원칙을 따르며 많은 성숙한 분석 및 설계 방법이 임베디드 분야에 적용될 수 있습니다. 임베디드 시스템의 개발 프로세스에는 요구 사항 분석, 시스템 설계, 구현 및 테스트 등 여러 기본 단계도 포함되며 각 단계에는 고유한 특성과 초점이 있습니다.
본 절에서는 임베디드 시스템 개발 및 설계에 관한 기술과 방법을 주로 소개하고, 임베디드 시스템 응용과 컴퓨팅 모델의 관점에서 응용 소프트웨어 설계 방법과 설계 과정에서 직면하는 주요 문제점을 분석한다. 마지막으로 임베디드 분야의 소프트웨어 이식과 관련된 이슈를 논의한다.
임베디드 시스템을 설계하기 전에 임베디드 시스템 설계 자체의 특성과 임베디드 시스템 설계를 측정하기 위한 몇 가지 주요 기술 지표를 명확히 해야 합니다.
1.임베디드 시스템 설계의 특징
일반적인 시스템 설계와 비교하여 임베디드 시스템 설계는 다음과 같은 특징을 갖습니다.
2.임베디드 시스템의 기술 지표
임베디드 시스템 설계에 일반적으로 사용되는 지표는 다음과 같습니다.
(1) NRE 비용(Non-recurring Engineering Cost): 시스템을 설계하기 위해 지불해야 하는 일회성 금전적 비용. 즉, 일단 설계가 완료되면 추가 설계 비용을 지불하지 않고 얼마든지 제품을 생산할 수 있다. .
(2) 단가 : NRE 비용을 제외한 단일 제품을 생산하는 데 필요한 금전적 비용.
(3) 크기: 시스템이 차지하는 공간을 말하며, 소프트웨어의 경우 일반적으로 바이트 수로 측정되고, 하드웨어의 경우 논리 게이트 또는 트랜지스터의 수로 측정됩니다.
(4) 성능: 시스템이 지정된 작업을 완료하는 데 필요한 시간은 설계 중에 가장 일반적으로 사용되는 설계 지표로 두 가지 주요 측정 방법이 있습니다. 하나는 실행 시작과 종료 사이의 시간입니다. 작업. 두 번째는 완료량, 즉 단위 시간당 완료한 작업의 양입니다.
(5) 전력: 시스템이 소비하는 전력으로, 배터리 수명이나 회로의 열 방출 요구 사항을 결정합니다.
(6) 유연성: NRE 비용을 늘리지 않고 시스템 기능을 변경할 수 있는 능력입니다.
(7) 프로토타입 생성 시간: 시스템의 실행 가능한 버전을 구축하는 데 필요한 시간입니다. 시스템 프로토타입은 최종 제품보다 크고 비용이 많이 들 수 있지만 시스템의 사용과 정확성을 검증하고 기능을 향상시킬 수 있습니다. 체계.
(8) 출시 시간: 시스템 개발부터 소비자에게 판매될 수 있을 때까지의 시간입니다. 가장 중요한 영향을 미치는 요소로는 설계 시간, 제조 시간 및 테스트 시간이 있습니다.
(9) 유지 관리성: 특히 원본 개발자가 아닌 사람이 시스템을 출시하거나 출시한 후 시스템을 쉽게 수정할 수 있는 정도입니다.
(10) 정확성: 시스템의 기능이 올바르게 구현되면 전체 설계 과정에서 시스템의 기능을 확인할 수 있으며, 올바른지 확인하기 위해 테스트 회로도 삽입할 수 있습니다.
(11) 안전성: 시스템이 해를 끼치지 않을 확률. 다양한 설계 지표는 일반적으로 서로 경쟁하며, 하나의 지표를 개선하면 다른 지표의 저하로 이어지는 경우가 많습니다. 설계 최적화 요구 사항을 가장 잘 충족하려면 설계자가 다양한 소프트웨어 및 하드웨어 구현 기술을 이해하고 이를 통해 배울 수 있어야 합니다. 특정 제약 조건 하에서 최상의 솔루션을 찾기 위해 기술이 다른 기술로 이전됩니다.
삼.임베디드 시스템 설계 과제
임베디드 시스템 설계가 직면한 과제는 다음과 같습니다.
(1) 필요한 하드웨어의 양: 설계자는 문제를 해결하는 데 사용되는 컴퓨팅 성능을 강력하게 제어할 수 있으며 사용할 프로세서뿐만 아니라 사용되는 메모리의 양, 사용되는 주변 장치 등도 선택할 수 있습니다. 성능 요구 사항을 충족하려면 제조 비용에 대한 제약도 있습니다. 하드웨어 선택이 매우 중요합니다. 하드웨어가 너무 적으면 기능 및 성능 요구 사항을 충족하지 못하고, 하드웨어가 너무 많으면 제품이 너무 비싸집니다.
(2) 시간 제한을 맞추는 방법: 시간 제한을 해결하기 위해 프로그램 실행 속도를 높이기 위해 프로세서 속도를 높이는 방법을 사용하는 것은 권장되지 않습니다. 이는 시스템 가격을 증가시킬 수 있기 때문입니다. 동시에, 프로세서의 클럭 주파수를 높여도 실행 속도가 향상되지 않는 경우가 있습니다. 프로그램 속도가 스토리지 시스템에 의해 제한될 수 있기 때문입니다.
(3) 시스템 전력 소비를 줄이는 방법: 배터리 구동 시스템의 경우 전력 소비는 매우 민감한 문제입니다. 배터리로 구동되지 않는 시스템의 경우 전력이 높다는 것은 열 방출이 높다는 것을 의미합니다. 시스템 전력 소비를 줄이는 한 가지 방법은 컴퓨팅 속도를 줄이는 것입니다. 그러나 단순히 컴퓨팅 속도를 줄이는 것만으로는 성능이 만족스럽지 못할 것입니다. 따라서 성능 제약을 충족하면서 전력 소비를 줄이려면 신중한 설계가 이루어져야 합니다.
(4) 시스템 확장성을 보장하는 방법: 시스템의 하드웨어 플랫폼은 여러 세대를 사용하거나 동일한 세대의 다른 수준의 제품을 사용할 수 있습니다. 이러한 경우에는 설계자가 시스템의 특성을 약간만 변경하면 됩니다. 소프트웨어를 변경하여 아직 소프트웨어에서 사용할 수 없는 성능 기능을 제공할 수 있는 기계를 설계합니다.
(5) 시스템의 신뢰성을 보장하는 방법: 신뢰성은 제품을 판매할 때 중요한 지표입니다. 제품이 잘 작동할 수 있다는 것은 소비자의 합리적인 요구 사항입니다. 안전 제어 시스템과 같은 일부 시스템에서는 신뢰성이 특히 중요합니다.
(6) 테스트의 복잡성: 임베디드 시스템을 테스트하는 것은 단지 일부 데이터를 입력하는 것보다 훨씬 어렵기 때문에 올바른 데이터를 생성하려면 전체 시스템을 실행해야 합니다. 임베디드 시스템을 떠나서 전체 환경과 협력하여 임베디드 시스템을 테스트하십시오.
(7) 제한된 가시성 및 제어 가능성: 임베디드 시스템에는 일반적으로 디스플레이 장치와 키보드가 없으므로 개발자가 시스템 내부에서 일어나는 일을 이해하기 어렵고 때로는 마이크로 컨트롤러를 관찰해야 합니다. 이해하라는 신호입니다. 실시간 시스템에서는 일반적으로 관찰을 위해 시스템을 종료하는 것이 불가능합니다.
(8) 제한된 개발 환경: 개발 소프트웨어, 하드웨어 도구 등 임베디드 시스템의 개발 환경은 일반적으로 범용 컴퓨터나 워크스테이션에서 사용할 수 있는 환경보다 더 제한적입니다. 개발 진행에 영향을 미칩니다.
일반 시스템 개발과 유사하게 임베디드 시스템 개발에도 소프트웨어 엔지니어링의 공통 개발 모델(주로 폭포 모델, 나선형 모델, 단계적 개선 모델, 계층 모델 포함)을 채택할 수 있습니다.
1.일반적인 개발 모델
설계 프로세스는 시스템 설계 중에 따라야 하는 일련의 단계로, 그 중 일부는 자동화된 도구로 수행할 수 있지만 일부는 수동으로만 수행할 수 있습니다. 임베디드 시스템 분야에서 일반적으로 사용되는 개발 프로세스 모델은 다음과 같습니다.
(1) 폭포 모델. 폭포 모델은 5가지 주요 단계로 구성됩니다. 요구 사항 분석 단계는 대상 시스템의 기본 특성을 결정하고, 시스템 구조 설계 단계는 시스템의 기능을 주요 구조로 분해하며, 테스트 단계는 주로 오류를 감지합니다. 마지막은 유지 관리 단계로, 환경 변화에 맞춰 코드를 수정하고, 오류를 수정하고, 업그레이드하는 일을 주로 담당합니다. 각 단계의 작업과 정보는 항상 높은 수준의 추상화에서 보다 세부적인 설계 단계로 한 방향으로 흐르며, 이는 이상적인 하향식 설계 모델입니다.
(2) 나선형 모델. 나선형 모델은 시스템의 여러 버전이 구축될 것이라고 가정합니다. 초기 버전은 설계자가 시스템에 대한 직관을 확립하고 이 시스템 개발 경험을 축적하는 데 도움이 되는 간단한 실험 모델입니다. 시스템. 설계의 각 계층에서 설계자는 수요 분석, 구조 설계 및 테스트의 세 단계를 거칩니다. 이후 단계에서 더 복잡한 버전의 시스템이 구축되면 각 단계에서 더 많은 작업이 수행되며 설계 나선을 확장해야 합니다. 이러한 단계별 접근 방식을 통해 디자이너는 자신의 수준을 심화할 수 있습니다. 일련의 설계 주기를 통해 개발된 시스템을 이해합니다. 나선형 상단의 첫 번째 루프는 매우 작고 짧은 반면, 나선형 하단의 마지막 루프는 나선형 모델의 초기 루프에 세부 정보를 추가하여 폭포 모델보다 더 사실적입니다.
(3) 모델을 단계별로 개선합니다. 단계적 개선 모델은 첫 번째 시스템을 프로토타입으로 사용한 후 시스템을 하나씩 추가로 개선하는 시스템입니다. 이 접근 방식은 설계자가 구축 중인 시스템의 애플리케이션 도메인에 대해 잘 알지 못하는 경우에 적합합니다. 복잡성이 증가하는 여러 시스템을 구축하여 시스템을 개선하면 설계자가 아키텍처와 설계 기술을 테스트할 수 있습니다. 또한 시스템이 최종적으로 완성될 때까지 다양한 반복 기술이 부분적으로만 완료될 수도 있습니다.
(4) 계층적 모델. 많은 임베디드 시스템 자체는 더 작은 디자인으로 구성되며 완전한 시스템에는 다양한 소프트웨어 구성 요소와 하드웨어 구성 요소가 필요할 수 있습니다. 이러한 부분은 아직 설계되지 않은 작은 부분으로 구성될 수 있으므로 전체 시스템의 초기 설계부터 개별 부품의 설계, 전체 설계에서 전체 설계까지 시스템의 추상화 수준에 따라 설계 프로세스가 변경됩니다. 최고 수준의 추상화에서 중간 수준까지의 세부 설계와 각 특정 모듈의 설계는 계층별로 전개됩니다. 각 프로세스는 단일 디자이너 또는 설계 팀에 의해 수행될 수 있습니다. 각 그룹은 다른 그룹의 결과에 의존합니다. , 각 그룹은 상사로부터 학습하고, 그룹은 요구사항을 획득하는 반면 상위 그룹은 개별 그룹 설계의 품질과 성능에 의존합니다. 또한 프로세스의 각 구현 단계는 사양부터 테스트까지 완전한 프로세스입니다.
2.임베디드 시스템 설계 방법
좋은 임베디드 시스템 설계 방법은 다음과 같은 이유로 매우 중요합니다.
(1) 좋은 디자인 방법은 디자이너가 자신이 하고 있는 작업의 진행 상황을 명확하게 이해하여 어느 하나도 놓치지 않도록 할 수 있습니다.
(2) 설계자가 작업하고 전체 프로세스를 여러 제어 가능한 단계로 나누는 데 도움이 되는 컴퓨터 지원 도구를 사용할 수 있습니다.
(3) 좋은 디자인 방법은 디자인 팀 구성원 간의 의사소통을 촉진합니다. 포괄적인 디자인 프로세스를 정의함으로써 팀의 각 구성원은 자신이 수행해야 하는 작업과 자신에게 할당된 작업을 완료하는 데 필요한 단계를 잘 이해할 수 있습니다. . 목표 달성.
임베디드 시스템 소프트웨어의 개발 과정은 프로젝트 기획, 타당성 분석, 요구사항 분석, 개요 설계, 상세 설계, 프로그램 생성, 다운로드, 디버깅, 구체화, 테스트 및 운영 등 여러 단계로 나눌 수 있습니다.
프로젝트 기획, 타당성 분석, 요구 사항 분석, 개요 설계 및 상세 설계 단계는 기본적으로 일반 소프트웨어 개발 프로세스와 동일하며 모두 프로토타이핑 방법, 구조화 방법 등 소프트웨어 엔지니어링 방법에 따라 수행될 수 있습니다. .
임베디드 소프트웨어는 실행 환경과 개발 환경이 다르기 때문에 개발 작업이 교차적으로 진행되므로 모든 단계에서 이를 고려해야 합니다. 프로그램 수립 단계의 작업은 상세 설계 단계에서 생성된 문서를 기반으로 이루어집니다. 이 단계의 작업에는 주로 소스 코드 작성, 컴파일 및 링크와 같은 여러 하위 프로세스가 포함됩니다. 이러한 작업은 모두 호스트 시스템에서 수행되며 대상 시스템을 사용할 필요가 없습니다. 애플리케이션의 실행 파일을 생성한 후 디버깅을 위해 크로스 개발 환경을 사용해야 합니다. 실제 상황에 따라 선택할 수 있습니다.
사용 가능한 여러 디버깅 방법 중 하나를 사용하거나 이들의 유효한 조합을 사용하여 이 작업을 수행합니다. 임베디드 시스템 설계는 그림 12-11에서 볼 수 있듯이 기존 소프트웨어 설계와 다릅니다. 종종 사양 및 시스템 아키텍처와 같은 프런트엔드 활동에서 하드웨어와 소프트웨어 측면을 모두 고려해야 하는 하드웨어 설계 및 소프트웨어 설계가 관련됩니다.
마찬가지로 시스템 통합 및 테스트와 같은 백엔드 설계도 전체 시스템을 고려합니다. 중간 단계에서는 소프트웨어와 하드웨어 구성요소가 서로 독립적으로 개발되며, 대부분의 하드웨어와 소프트웨어 작업은 상대적으로 독립적으로 수행될 수 있습니다. 마지막으로, 디버깅 후 올바른 실행 프로그램이 대상 컴퓨터에서 구체화되어야 합니다.임베디드 시스템 하드웨어의 구성에 따라 EPROM, FLASH와 같은 메모리나 DOC, DOM과 같은 전자 장치에서 경화하는 방법이 여러 가지가 있습니다.
서브 플레이트. 일반적으로 일부 특수 프로그래머의 도움을 받아 수행됩니다.
임베디드 시스템은 범용 컴퓨터 시스템보다 보안 및 신뢰성 요구 사항이 높기 때문에 임베디드 시스템의 화이트박스 테스트를 수행할 때는 더 높은 코드 적용 범위가 필요합니다. 시스템 개발 프로세스의 각 단계에서는 시스템 확인 및 성능 평가, 보안 평가 및 위험 평가가 수행되어야 하며 시스템 구현을 테스트하고 검증해야 합니다.
임베디드 시스템의 개발은 소프트웨어와 하드웨어의 포괄적인 개발로, 일반적인 시스템의 개발과는 매우 다릅니다. 반면에 각 임베디드 시스템은 소프트웨어와 하드웨어의 조합입니다. 소프트웨어는 하드웨어와 함께 제품으로 굳어지며 강한 특수성을 갖는다. 이러한 특성의 영향으로 임베디드 시스템의 개발 프로세스를 지원하기 위해서는 일반적인 소프트웨어 개발 프로세스와는 다른 엔지니어링 방법론이 있어야 하며, 동시에 이러한 특성은 임베디드 시스템 개발에 사용되는 고유한 핵심 기술을 결정하기도 합니다.
일반적으로 임베디드 개발 분야에는 프로세서 기술, IC 기술, 설계/검증 기술의 세 가지 주요 핵심 기술이 있습니다.
1. 프로세서 기술
프로세서 기술은 시스템 기능을 구현하는 컴퓨팅 엔진 구조와 관련이 있습니다. 프로그래밍이 불가능한 많은 디지털 시스템도 프로세서로 간주할 수 있습니다. 이러한 프로세서의 차이점은 특정 기능에 대한 전문화 정도에 따라 다른 프로세서와 설계 사양이 다릅니다. .
(1) 범용 프로세서. 이러한 유형의 프로세서는 다양한 유형의 애플리케이션에 사용될 수 있습니다. 중요한 특징은 프로그램을 저장하는 기능입니다. 설계자는 프로세서가 어떤 작업을 수행할지 모르기 때문에 디지털 회로를 사용하여 프로그램을 만드는 것은 불가능합니다. 또 다른 특징은 다양한 계산을 처리하기 위해 데이터 경로가 일반적으로 많은 수의 레지스터와 하나 이상의 범용 산술 논리 장치를 갖는다는 것입니다. 설계자는 필요한 기능을 수행하기 위해 프로세서의 메모리, 즉 설계 관련 소프트웨어만 프로그래밍하면 됩니다.
임베디드 시스템에서 범용 프로세서를 사용하면 설계 지표 측면에서 몇 가지 이점이 있습니다. 설계자가 디지털 설계를 하지 않고 프로그램만 작성하면 되므로 출시 기간과 NRE 비용이 저렴합니다. 이는 유연성이 뛰어나고 프로그램 수정을 통해 기능 변경이 가능합니다. 프로세서 자체 설계에 비해 수량이 적을수록 단가가 낮아집니다.
물론 이 방법은 설계 지표에 있어서도 몇 가지 결함이 있습니다. 수량이 많으면 단가가 상대적으로 높기 때문에 자체 설계한 NRE의 비용이 상각되어 단가를 줄일 수 있기 때문입니다. 동시에 일부 애플리케이션의 경우 성능이 저하될 수 있습니다. 불필요한 프로세서 하드웨어를 포함하면 시스템 크기와 전력 소비가 증가할 수 있습니다.
(2) 단일 목적 프로세서. 단일 목적 프로세서는 특정 프로그램을 실행하도록 설계된 디지털 회로이며 보조 프로세서, 가속기, 주변 장치 등을 의미하기도 합니다. JPEG와 같은 코덱은 단일 프로세스를 실행하여 비디오 정보를 압축하거나 압축을 해제합니다. 임베디드 시스템 설계자는 특정 디지털 회로를 설계하여 단일 목적 프로세서를 만들 수 있습니다. 설계자는 사전 설계된 상업용 단일 목적 프로세서를 사용할 수도 있습니다.
임베디드 시스템에서 단일 목적 프로세서를 사용하면 측정 기준 측면에서 몇 가지 장점과 단점이 있습니다. 이러한 장점과 단점은 기본적으로 범용 프로세서와 정반대이며, 성능이 더 좋을 수 있고, 크기와 전력이 더 작을 수 있으며, 수량이 많을수록 단가가 낮아질 수 있으며, 설계 시간과 NRE 비용이 높을 수 있습니다. 유연성이 떨어지고 시간당 단위 비용이 높으며 일부 응용 프로그램의 경우 성능이 범용 프로세서만큼 좋지 않습니다.
(3) 전용 프로세서. 특수 목적 명령어 세트 프로세서는 특정 유형의 애플리케이션에 최적화된 프로그래밍 가능 프로세서입니다. 이러한 특정 애플리케이션은 임베디드 제어, 디지털 신호 처리 등과 같은 동일한 특성을 갖습니다. 임베디드 시스템에서 전용 프로세서를 사용하면 우수한 성능, 전력 및 크기를 보장하면서 더 큰 유연성을 제공할 수 있지만 이러한 프로세서는 여전히 프로세서 자체와 컴파일러를 구축하는 데 값비싼 비용이 필요합니다. 마이크로컨트롤러와 디지털 신호 프로세서는 널리 사용되는 두 가지 유형의 특수 프로세서입니다. 디지털 신호 프로세서는 디지털 신호에 대해 일반적인 작업을 수행하는 마이크로프로세서이고, 마이크로컨트롤러는 임베디드 제어 프로세서에 최적화된 마이크로프로세서입니다.
2. IC 기술
시스템의 집적회로 설계 기술로부터 실제 칩의 물리적인 매핑 과정을 얻는 구현 기술은 IC(Integrated Circuits, 집적 회로) 기술이다. 현재 반도체 분야에는 풀 커스터마이징(fullcustomization)이라는 세 가지 구현 기술이 있다. , 반맞춤화 및 프로그래밍 가능 기술을 임베디드 시스템의 하드웨어 설계에 적용할 수 있습니다.
(1) 완전 맞춤형/VLSI(Very Large Scale Integrated Circuits, 초대형 집적 회로). 완전 맞춤형 IC 기술에서 각 계층의 설계자는 특정 임베디드 시스템의 디지털 구현을 최적화해야 합니다. 설계자는 트랜지스터의 레이아웃 크기, 위치 및 배선부터 시작하여 높은 칩 면적 활용도, 빠른 속도 및 낮은 전력 소비를 달성해야 합니다. . 성능을 최적화합니다. 마스크를 사용하여 제조 공장에서 실제 칩을 생산하는 완전 맞춤형 IC 설계(VLSI라고도 함)는 NRE 비용이 높고 제조 시간이 길며 대용량 또는 성능이 중요한 애플리케이션에 적합합니다.
(2) 세미 맞춤형/ASIC(주문형 집적 회로, 주문형 집적 회로). Semi-custom ASIC은 게이트 어레이 설계 방법과 표준 셀 설계 방법을 포함하는 제한된 설계 방법입니다. 이는 일부 범용 장치 구성 요소와 구성 요소 그룹이 칩에 만들어진 반제품 하드웨어입니다. 설계자는 회로의 논리적 기능과 기능 모듈 간의 합리적인 연결만 고려하면 됩니다. 이 설계 방법은 유연하고 편리하며 비용 효율적이며 설계 주기를 단축하고 수율을 향상시킵니다.
(3) 프로그래밍 가능/ASIC. 프로그래밍 가능 장치의 모든 레이어는 이미 존재합니다. 설계가 완료된 후에는 IC 제조업체의 개입 없이 설계된 칩을 실험실에서 실행할 수 있으며 개발 주기가 크게 단축됩니다. 프로그래밍 가능 ASIC은 NRE 비용이 낮고 단위 비용이 높으며 전력 소비가 높으며 속도가 느립니다.
삼.설계/검증 기술
임베디드 시스템의 설계 기술은 크게 하드웨어 설계 기술과 소프트웨어 설계 기술로 나뉜다. 그 중 하드웨어 설계 분야의 기술은 주로 칩 레벨 설계 기술과 회로 기판 레벨 설계 기술을 포함한다.
칩레벨 설계 기술의 핵심은 컴파일/합성, 라이브러리/IP(지식재산권, 지식재산권), 테스트/검증입니다. 컴파일/합성 기술을 통해 설계자는 필요한 기능을 추상적인 방식으로 설명하고 구현 세부 사항을 자동으로 분석 및 삽입할 수 있습니다. 라이브러리/IP 기술은 높은 수준의 추상화를 위해 미리 설계된 낮은 수준의 추상화 구현을 사용합니다. 테스트/검증 기술은 각 레벨이 올바르게 작동하는지 확인하여 레벨 간 반복 설계 비용을 절감합니다.
소프트웨어 설계 기술의 핵심은 소프트웨어 언어이다. 소프트웨어 언어는 저급 언어(기계어, 어셈블리 언어)부터 고급 언어(예: 구조적 설계 언어, 객체 지향 설계 언어)까지의 개발 과정을 경험해 왔습니다. 조립기술, 분석기술, 편집/해석기술 등 다양한 관련 기술. 소프트웨어 언어의 수준도 구현 수준, 설계 수준, 기능 수준에서 수요 수준의 언어 개발로 점차 전환되고 있습니다.
초기에는 범용 프로세서 개념이 점진적으로 형성되면서 소프트웨어 기술이 급속히 발전하고, 소프트웨어의 복잡성도 증가하기 시작했으며, 소프트웨어 설계와 하드웨어 설계의 기술 및 분야가 완전히 분리되었다. 디자인 기술과 도구는 이 두 분야에서 동시에 개발되어 점점 더 추상적인 수준에서 동작 설명을 수행하여 점점 늘어나는 디자인 복잡성 요구에 적응할 수 있게 되었습니다. 이러한 동시 개발을 통해 이제 두 필드가 동일한 타이밍 모델을 사용하여 동작을 설명하므로 두 필드가 다시 하나의 필드로 통합될 가능성이 있습니다.
대부분의 임베디드 시스템이 실시간 반응형 시스템이라는 점을 고려하여 반응형 시스템은 다중 작업 동시성, 엄격한 시간 제약 및 높은 신뢰성의 특성을 가지고 있습니다. 반응형 시스템의 설계 및 설명을 위해 사람들은 다양한 제안을 계속해 왔습니다. 설명 언어 및 검증 방법론. 예를 들어, 순차 논리는 리액티브 시스템의 특성과 리액티브 시스템의 동작에 대한 이유를 설명하는 데 사용되며 모델 확인 기술은 리액티브 시스템 설계의 정확성을 검증하는 데 사용됩니다. 이러한 기술은 점차 임베디드 개발에서 중요한 역할을 해왔습니다. 프로세스. .
임베디드 시스템을 위한 개발 환경에는 다양한 유형이 있으며 일반적으로 다음 범주로 나눌 수 있습니다.
(1) 임베디드 운영 체제를 지원하는 개발 환경 이 범주에는 PalmOS, THOS, VxWorks, Windows CE 및 기타 상용 임베디드 운영 체제와 같이 이를 지원하는 완전한 기능을 갖춘 개발 환경이 많이 있습니다.
(2) 프로세서 칩을 지원하는 개발 환경. 이러한 유형의 개발 환경은 일반적으로 프로세서 제조업체에서 제공합니다. 예를 들어 S1C33 시리즈 마이크로 컨트롤러 칩을 기반으로 하는 임베디드 시스템 개발을 위해 특별히 EPSON에서 출시한 도구 키트가 이러한 유형의 개발 환경입니다.
(3) 특정 애플리케이션 플랫폼에 맞는 개발 환경. 이러한 유형의 개발 환경은 Qualcomm의 Brew SDK와 같이 고도로 타겟팅되어 있습니다.
(4) 기타 유형의 개발 환경. 이러한 유형의 개발 환경은 주로 GNU 오픈 소스 도구를 기반으로 일부 임베디드 시스템 공급업체가 개발하거나 사용자 정의한 보다 일반적인 개발 환경을 나타냅니다. 이러한 도구는 무료로 제공되며 다양한 프로세서 유형을 지원하고 완전한 기능을 갖추고 있지만 기술 지원은 전문 상용 도구에 비해 약간 열등합니다.
임베디드 시스템의 기능이 점점 복잡해짐에 따라 기능적으로 복잡한 시스템의 동작을 설명하는 것이 점점 더 어려워지고 있습니다. 실제로 계산 모델을 사용하여 시스템을 설명하고 분석하는 것이 엔지니어링 가치가 있는 방법이라는 것이 입증되었습니다.
이 섹션에서는 임베디드 분야에서 일반적으로 사용되는 몇 가지 컴퓨팅 모델을 소개하고, 임베디드 애플리케이션 설계 및 개발과 관련된 문제를 컴퓨팅 모델 관점에서 분석하고 설명합니다. 계산 모델은 복잡한 동작을 간단한 개체와 결합하는 일련의 방법을 제공하므로 설계자가 시스템 동작을 이해하고 설명하는 데 도움이 될 수 있습니다. 임베디드 시스템에서 일반적으로 사용되는 컴퓨팅 모델에는 순차 컴퓨팅 모델, 통신 프로세스 모델, 상태 머신 모델, 데이터 흐름 모델, 객체 지향 모델 및 동시 프로세스 모델이 포함됩니다. 이러한 모델은 다양한 응용 분야에서 사용됩니다. 예를 들어 상태 기계 모델은 제어 지향 시스템을 설명하는 데 특히 적합하며 데이터 흐름 모델은 데이터 처리 및 변환 문제를 잘 설명할 수 있습니다. 현재 가장 널리 사용되는 것은 동시 프로세스 모델이다.
1.상태 머신 모델
FSM(Finite-State Machine)은 가능한 상태 집합을 사용하여 시스템의 동작을 설명할 수 있는 기본 상태 모델입니다. 시스템은 언제든지 상태 중 하나만 있을 수 있거나 결정된 상태를 설명할 수도 있습니다. 마지막으로 전환은 특정 상태에서 또는 상태 전환 중에 발생할 수 있는 작업을 설명할 수 있습니다.
유한 상태 기계 FSM은 6개의 튜플 F입니다.<S，I，O，F，H，S0> 여기서 S는 상태 세트 {s0, s1,…,sl}이고, I는 입력 세트 {I0, I1,…,Im}이고, O는 출력 세트 {o0, o1,…,on}이고, F는 또는 상태와 입력을 상태(S×I→S)로 매핑하는 전이 함수, H는 상태를 출력(S→O)으로 매핑하는 출력 함수, S0는 초기 상태입니다. .
그림 12-12는 엘리베이터 제어 장치의 상태 기계 설명입니다. 초기 "idle" 상태에서 0으로 설정하고 1로 오픈합니다. 상태 머신은 요청된 층이 현재 층과 다를 때까지 "유휴" 상태로 유지됩니다. 요청된 층이 현재 층보다 크면 상태 머신은 "up" 상태로 전환되어 1로 설정됩니다. 요청된 층이 현재 층보다 작은 경우 상태 머신은 "down" 상태로 이동하고 down은 1로 설정됩니다. 상태 기계는 현재 층이 요청된 층과 같아질 때까지 "down" 또는 "up" 상태를 유지한 다음 상태가 open이 1로 설정된 "open" 상태로 전환됩니다. 일반적으로 시스템에는 타이머가 있습니다. 따라서 상태 기계가 "문 열림" 상태로 전환되면 타이머도 시작됩니다. 타이머 시간이 초과될 때까지 상태 기계는 "문 열림" 상태를 유지하고 최종적으로 다음으로 전환됩니다. "유휴" 상태.
FSM이 임베디드 시스템 설계에 사용될 때 입력과 출력의 데이터 유형은 모두 부울 유형이며, 함수는 부울 연산을 포함하는 부울 함수를 나타냅니다. 이 모델은 데이터 입력 또는 출력이 충분하지 않은 많은 순수 제어 시스템에 사용되었습니다. . 데이터를 처리하려면 FSM을 데이터 경로가 있는 상태 머신(FSM with Datapath, FSMD)으로 확장하세요. 또한 상태 머신 모델은 계층적 및 동시성을 지원하도록 더욱 확장될 수 있습니다. 이 모델을 계층적/동시 FSM(HCFSM) 모델이라고 합니다.
2.데이터 흐름 모델
데이터 흐름 모델은 동시 다중 작업 모델에서 파생된 모델입니다. 이 모델은 시스템의 동작을 노드와 가장자리의 집합으로 설명합니다. 여기서 노드는 변환을 나타내고 가장자리는 한 노드에서 다른 노드로의 데이터 흐름을 나타냅니다. . 각 노드는 입력 가장자리의 데이터를 사용하고 변환을 수행하며 출력 가장자리에 데이터를 생성합니다.
각 엣지에는 데이터가 있을 수도 있고 없을 수도 있습니다. 엣지에 나타나는 데이터를 토큰이라고 합니다. 노드의 모든 입력 엣지에 하나 이상의 토큰이 있으면 해당 노드가 트리거될 수 있습니다. 노드가 트리거된 후 각 입력 에지의 토큰이 사용되고, 사용된 모든 토큰에 대해 데이터 변환이 수행되며, 출력 에지에서 토큰이 생성됩니다. 노드의 트리거는 토큰 발생에만 의존합니다. .
그림 12-13은 z=(a+b)×(cd)를 계산하기 위한 데이터 흐름 모델을 보여줍니다. 현재 그래픽 언어로 데이터 흐름 모델 표현을 지원하는 여러 상용 도구가 있습니다. 이러한 도구는 데이터 흐름 모델을 마이크로프로세서 구현을 위한 동시 다중 작업 모델로 자동 변환할 수 있습니다. 변환 방법은 각 노드를 작업으로, 각 에지를 채널로 변환하는 것입니다. 동시 다중 작업 모델의 구현 방법은 실시간 운영 체제를 사용하여 동시 작업을 매핑하는 것입니다.
그림 12-14는 동기식 데이터 흐름 모델입니다. 이 모델에서는 노드의 각 입력 에지와 출력 에지가 각 트리거에 사용 및 생성된 토큰 수로 표시됩니다. 이 모델의 장점은 구현 중에 동시 다중 작업 모델로 변환할 필요가 없다는 것입니다. 대신 노드는 순차적 프로그램 모델을 생성하기 위해 정적 방식으로 예약됩니다. 모델은 순차 프로그래밍 언어(예: C 언어)를 사용하여 표현할 수 있고 실시간 운영체제 없이도 실행할 수 있어 실행 효율성이 더 높습니다.
3. 동시 프로세스 모델
동시 프로세스 모델은 프로세스 그룹으로 구성됩니다. 각 프로세스는 순차적 실행 프로세스이며 각 프로세스는 동시에 실행될 수 있습니다. 동시 프로세스 모델은 프로세스 생성, 종료, 일시 중지, 재개 및 연결을 위한 작업을 제공합니다. 프로세스는 실행 중에 서로 통신하고 데이터를 교환할 수 있습니다. 프로세스 간 통신은 공유 변수와 메시지 전달이라는 두 가지 형태를 취할 수 있습니다. 세마포어, 임계 섹션, 튜브, 경로 표현 등은 동시 프로세스의 작업을 동기화하는 데 사용됩니다.
일반적으로 실시간 시스템은 동시에 실행되는 여러 프로세스로 구성된 시스템으로 볼 수 있으며 각 프로세스에는 시간 요구 사항이 있습니다. 이러한 방식으로 많은 임베디드 시스템은 동시에 실행되는 작업 세트로 더 쉽게 설명됩니다. 왜냐하면 이러한 시스템 자체는 멀티 태스킹 시스템이고 동시 프로세스 모델은 자연스럽게 실시간 운영 체제의 멀티 태스킹으로 구현될 수 있기 때문입니다.
4.객체지향 모델
전통적인 동시 프로세스 모델은 프로세스 개념을 중심으로 설계되었습니다. 프로세스는 객관적인 세계의 활동을 간접적으로 시뮬레이션하는 것입니다. 따라서 프로세스 모델을 사용하여 동시성 문제를 해결하는 것은 매우 어렵습니다. 객관적인 세계는 부자연스럽고 동시성 프로그램을 설계하고 이해하기 어렵게 만듭니다.
객체 지향 모델은 객관적인 세계의 활동을 보다 직접적인 방식으로 설명하며 모델에는 잠재적인 동시 실행 기능이 있습니다. 한 개체가 다른 개체에 메시지를 보낸 후 메시지의 처리 결과가 필요하지 않거나 즉시 필요하지 않은 경우 전자는 후자가 메시지를 처리할 때까지 기다릴 필요가 없으며 메시지 보낸 사람과 메시지 수신자는 다음을 실행할 수 있습니다. 동시에.객체는 모두 수동적인 서비스 제공 상태가 아니며, 메시지를 수신하여 서비스를 제공하는 것 외에도 일부 객체는 자체 트랜잭션 처리를 가질 수도 있습니다.
이유. 객체는 종종 여러 메시지를 동시에 처리할 수 있습니다.
객체는 데이터와 연산의 캡슐화입니다. 데이터는 객체의 지역 변수에 저장됩니다. 객체의 상태는 특정 순간의 객체의 모든 지역 변수의 값으로 표시됩니다. 동시성 환경에서는 객체의 동시성 제어가 객체의 동시 상태를 기반으로 하기 때문에 객체의 동시 상태에 대한 설명도 고려해야 합니다. 동시성과 객체지향을 결합하는 방법은 두 가지로 요약할 수 있습니다.
(1) 객체지향 모델에 동시성 메커니즘을 도입하고 객체지향 기술을 최대한 활용하여 객관적 세계의 우수한 모델 능력과 객체지향의 다양한 중요한 특성을 설명하는 동시에 잠재적인 동시성 능력을 설명합니다. , 동시 컴퓨팅을 설명하는 데 적합합니다.
(2) 전통적인 동시성 모델에 객체지향적 사고를 도입합니다. 객체 지향 동시성 모델은 암시적 동시성 모델과 명시적 동시성 모델의 두 가지 유형으로 나눌 수 있습니다.
(1) 암시적 동시성 모델. 이 모델은 동시 설계를 연기하고 객체 모델링을 모델링의 기초로 사용하는 것이 특징입니다. 실행 단계에 들어가기 전에 개체를 자율 단위로 처리하고 다양한 개체의 활동을 이상적인 동시 방식으로 완료되는 특정 작업으로 처리합니다. 각 개체에 자체 프로세서가 있는 것처럼 이 프로세서는 개체에 대한 실행 스레드를 제공할 수 있습니다. 시스템에 들어오는 외부 이벤트는 처리 요청으로 간주되어 일부 개체에 브로드캐스팅됩니다. 그런 다음 이러한 개체는 다른 개체에 추가 처리 요청을 보냅니다. 이론적으로 요청에 따라 원하는 수의 개체가 해당 처리를 수행할 수 있습니다. 구현 중에 스케줄러는 그림 12-15에 표시된 대로 해당 객체에 대한 작업 순서를 궁극적으로 결정합니다.
(2) 명시적 동시성 모델. 이 모델의 특징은 동시성을 먼저 고려하고, 동시성 개념과 객체 개념을 먼저 분리해야 한다는 점이다. 객체가 확립된 후에는 실시간 운영체제에서 지원하는 프로세스 개념을 사용하여 동시성을 표현하는데, 객체와 프로세스의 두 가지 추상적인 수준을 형성한다. 즉, 먼저 시스템을 준동시적 프로세스로 분해하여 시작한다. 각 프로세스 내에서 객체 지향 기술을 사용합니다. 객체 간의 상호 작용은 중첩된 함수 호출로 표현되며 잠금, 모니터, 세마포어와 같은 명시적인 동기화 메커니즘이 추가되어 객체의 무결성을 보장합니다. 이 모델은 프로세스를 개체 위에 배치하므로 그림 12-16에 표시된 것처럼 개체의 동시성이나 개체 직렬화를 고려할 필요가 없습니다.
초기 실시간 시스템의 설계 방식은 주로 구조화된 설계 방식이었다. 구조화된 방식을 사용하는 시스템은 재사용성과 수정 가능성 측면에서 큰 한계를 갖고 있었다. 객체지향 실시간 시스템 설계 방법은 이러한 문제에 있어 분명한 이점을 가지고 있습니다. 보다 실용적인 객체지향 설계 방식은 Nokia의 OCTOPUS 방식입니다. 이 방식은 OMT와 Fusion 방식을 기반으로 실시간 시스템 응답 시간, 시간 영역, 동시성을 처리하는 방식을 제안하며, 구체적으로 실시간 처리 방식을 제안합니다. 시스템 응답 시간, 시간 도메인 및 동시성 처리 측면, 동기화, 통신, 인터럽트 처리, ASIC, 하드웨어 인터페이스, 종단 간 응답 시간 등 OCTOPUS 접근 방식은 소프트웨어 개발의 주요 단계를 잘 결합하고 사양에서 실행 모델까지 긴밀하고 자연스러운 전환을 제공하며 점진적인 개발을 지원합니다. OCTOPUS 방식은 현재의 객체지향 기술과 실시간 시스템을 결합한 대표적인 설계 방식이다. 또한, 실시간 시스템 모델링의 초기 단계에서는 정형적인 객체지향 개발 기법과 모델링 언어가 점차 적용되고 있다.
디자인하기 전에 디자이너는 무엇을 디자인할지 알아야 합니다. 요구 사항과 사양은 서로 관련되어 있지만 서로 다른 설계 프로세스의 두 단계를 설명하는 데 자주 사용됩니다. 요구 사항은 사용자가 원하는 것에 대한 비공식적인 설명인 반면, 사양은 시스템 아키텍처를 만드는 데 사용할 수 있는 보다 자세하고 정확하며 일관된 설명입니다. 물론 요구 사항과 사양은 내부 표현이 아닌 지침 시스템의 외부 표현입니다. 요구사항에는 두 가지 유형이 있습니다. 기능적 요구사항과 비기능적 요구사항은 시스템이 수행해야 하는 작업을 설명하는 반면, 비기능적 요구사항은 물리적 크기, 가격, 전력 소비, 설계 시간, 신뢰성과 같은 시스템의 다른 속성을 설명합니다. 기다리다.
대규모 시스템의 요구 사항 분석은 복잡하고 시간이 많이 걸리는 작업이지만 명확하고 간단한 형식으로 소량의 정보를 얻는 것은 시스템 요구 사항을 이해하는 데 좋은 시작입니다. 표 12-5는 프로젝트 초기에 작성하는 요구사항 양식으로, 시스템의 기본 특성을 고려할 때 체크리스트로 활용할 수 있다.
본 요구사항 양식의 내용은 GPS(Global Position System, 모바일 지도 시스템)을 예로 들어 작성되었습니다. 모바일 지도 시스템은 고속도로를 운전하는 사용자나 이와 유사한 사용자를 위해 설계된 휴대용 장치입니다. 이 장치는 GPS로부터 위치 정보를 얻고 사용자에게 현재 위치와 주변 지형 지도를 표시할 수 있습니다. 사용자 및 기기의 위치에 따라 변경됩니다.
요구 사항 분석 단계에서 가장 중요한 문서 출력은 시스템 사양입니다.
사양이란 고객의 요구를 정확하게 반영하고 설계 시 준수해야 하는 요구사항을 담은 기술 문서입니다. 소프트웨어 개발 과정에서 사양은 매우 중요합니다. 시스템 분석가는 사용자 요구 사항을 수용하고 대상 소프트웨어 시스템에 대한 사양을 생성합니다. 설계자와 코더는 사양에 따라 모듈을 설계하고 최종적으로 프로그램 코드를 생성합니다. 최종 소프트웨어가 사양을 충족하는지 확인합니다. 사양은 명확하고 모호하지 않아야 합니다. 그렇지 않으면 사양에 따라 구축된 시스템이 실제 요구 사항을 충족하지 못할 수 있습니다.
현재 업계에서 가장 널리 사용되는 방법은 UML을 사용하여 사양을 설명하는 것입니다. UML은 정적 구조와 동적 동작으로 모든 시스템을 모델링할 수 있는 보편적인 표준 모델링 언어입니다. UML은 요구 사항 사양부터 시스템 완료 후 테스트까지 시스템 개발 프로세스의 다양한 단계에 적합합니다. 그림 12-17은 작업을 보여주는 상태 머신 사양의 예입니다. 시작과 끝은 특수 상태이며 상태 머신의 상태는 서로 다른 개념적 작업을 나타냅니다.
요구사항 분석 단계에서는 사용 사례를 통해 사용자 요구사항을 파악합니다. 유스케이스 모델링을 통해 시스템에 관심이 있는 외부 행위자와 시스템에 대한 기능적 요구사항(유스케이스)을 설명합니다. 분석 단계에서는 주로 문제 영역의 주요 개념(예: 추상화, 클래스, 개체 등) 및 메커니즘과 관련되며 이러한 클래스와 해당 관계를 식별하고 UML 클래스 다이어그램으로 설명하는 것이 필요합니다. 분석 단계에서는 소프트웨어 시스템의 기술적 세부 사항을 정의하는 클래스(예: 사용자 인터페이스, 데이터베이스, 통신 등의 문제를 처리하는 클래스)를 고려하지 않고 문제 영역의 개체(실제 개념)만 모델링됩니다. 및 병렬성).
현재 임베디드 시스템 설계 도구는 협업 합성 도구와 협업 시뮬레이션 도구라는 두 가지 범주로 나눌 수 있습니다.
(1) 공동 합성 도구. 현재 임베디드 개발에 사용되는 주요 협업 합성 도구로는 POLIS, COSYMA, Chinook 등이 있습니다.
POLIS: POLIS는 UC-Berkeley에서 개발한 대화형 임베디드 시스템을 위한 소프트웨어 및 하드웨어 공동 설계 프레임워크입니다. 시스템 설명은 FSM(Finite State Machine) 기반 언어를 지원합니다. 동일한 CFSM 설명에서 소프트웨어와 하드웨어를 모두 투명하게 얻을 수 있으므로 그에 따라 설계 공간의 유연성도 향상됩니다. 설명 및 구현 계층 모두에서 형식 검증이 지원됩니다. 즉, 하드웨어 CFSM은 하나의 프로세서로만 둘러싸여 있으며 공유 메모리를 지원하지 않습니다.
COSYMA: COSYMA는 하드웨어 및 소프트웨어 공동 설계의 합성 프로세스를 탐색하기 위해 독일 IDA 회사에서 개발한 플랫폼입니다. 소프트웨어 시스템에 대한 설명이 비교적 간단하고 자동 분할 및 보조 프로세서 합성을 지원하며 설계 공간을 탐색할 수 있습니다. 합성 기간 동안 시스템 합성은 하드웨어 제한에 따라 다르며 동시성 모듈을 지원하지 않습니다. 즉, 한 번에 하나의 스레드만 실행할 수 있으며 아키텍처도 제한되어 있으며 설계 성공을 지원하지 않습니다. 분할 및 비용 추정 기술에 따라 다릅니다.
Chinook: Chinook은 전체 시스템에 대한 설명을 입력으로 제공하며, 내부 모델은 계층적 상태형 모델을 기반으로 하여 단일 시뮬레이션 환경을 제공합니다. 전체 설계 Chinook은 다양한 시스템 아키텍처, 특히 다중 프로세서 아키텍처를 지원합니다. 또한 타이밍 제약 조건에 대한 설명을 지원하며 시스템 간의 소프트웨어 및 하드웨어 인터페이스를 포함한 다양한 인터페이스를 합성할 수 있으며 타이밍 차트에서 직접 장치 드라이버를 합성하고 프로세서 간의 통신을 제어할 수 있습니다.
(2) 협업 시뮬레이션 도구. 협업 시뮬레이션은 임베디드 시스템 설계에서 중요한 측면입니다. 전체 시스템 설계가 완료된 후에는 통합된 프레임워크에서 다양한 유형의 구성요소를 시뮬레이션해야 합니다. 협업 시뮬레이션은 검증을 제공할 뿐만 아니라 사용자에게 각 시스템의 성능 정보를 제공합니다. . 이는 큰 손실을 초래하지 않고 시스템 초기 단계에서 변경 사항을 제안하는 데 도움이 됩니다. 현재 두 가지 주요 협업 시뮬레이션 도구가 있습니다.
PTOLEMY: PTOLEMY의 핵심 아이디어는 컴퓨팅 모델과 객체 지향 커널을 혼합하는 것입니다. 다양한 시스템을 시뮬레이션하는 데 사용할 수 있으며 다양한 응용 프로그램에 널리 사용되지만 시스템 하드웨어 시뮬레이션에는 적합하지 않습니다. 또한 그 기능 중 하나입니다. TSS: TSS(Tool for System Simulation)는 복잡한 하드웨어를 시뮬레이션하기 위한 도구로, 개별 모듈의 추출을 사용자가 제어할 수 있으며, 모듈을 쉽게 추가하고 삭제할 수 있습니다. 그러나 계층적 모듈은 지원되지 않으며, 각 프로세서별로 공유 데이터 구조에 대한 액세스를 동기화하는 메커니즘이 없습니다. 또한 TSS는 멀티 코어 시스템의 시뮬레이션을 지원합니다.
1.시스템 아키텍처 설계
시스템이 사양에 정의된 기능을 어떻게 구현하는지 설명하는 것이 시스템 아키텍처 설계의 주요 목적입니다. 그러나 임베디드 시스템의 시스템 구조를 설계할 때 소프트웨어와 하드웨어를 완전히 분리하는 것은 어렵다. 일반적인 접근 방식은 시스템의 소프트웨어 아키텍처를 먼저 고려한 다음 하드웨어 구현을 고려하는 것입니다. 시스템 아키텍처에 대한 설명은 기능적 요구사항과 비기능적 요구사항을 모두 충족해야 합니다. 필요한 기능을 구현해야 할 뿐만 아니라 비용, 속도, 전력 소비 등 비기능적 제약도 충족해야 합니다. 시스템의 원래 블록 다이어그램에 있는 기능 요소를 하나씩 고려하고 개선하며, 비기능적 제약 조건을 고려하면서 원래 블록 다이어그램을 소프트웨어 및 하드웨어 시스템 구조로 변환하는 것은 실용적인 방법입니다. 다음은 GPS 모바일 지도 시스템의 아키텍처 설계를 예로 들어 설명합니다.
(1) 원본 블록 다이어그램. 그림 12-18에서 볼 수 있듯이 이 원본 블록 다이어그램은 모바일 지도 시스템의 주요 작업 및 데이터 흐름입니다.
(2) 소프트웨어 시스템 아키텍처. 그림 12-19에서 볼 수 있듯이 소프트웨어 시스템은 주로 사용자 인터페이스, 데이터베이스 검색 엔진 및 데이터 변환기로 구성됩니다.
(3) 하드웨어 시스템 아키텍처. 그림 12-20에서 볼 수 있듯이 하드웨어 시스템은 범용 마이크로프로세서, 메모리, I/O 장치로 구성됩니다. 이 시스템은 일반 데이터, 프로그램 메모리, 픽셀 디스플레이용 프레임 버퍼 메모리 등 두 가지 종류의 메모리를 선택합니다.
2.하드웨어 하위 시스템 설계
임베디드 시스템의 개발 환경은 대상 하드웨어 플랫폼, 임베디드 운영 체제, 프로그래밍 언어 및 개발 도구의 4가지 부분으로 구성됩니다. 그 중에서 프로세서 및 운영 체제 선택은 프로젝트 진행에 영향을 미치는 잘못된 결정을 피하기 위해 더 많은 요소를 고려해야 합니다. .
(1) 프로세서 기술을 선택합니다. 임베디드 시스템 설계의 주요 과제는 경쟁 설계 사양을 동시에 최적화하는 방법입니다. 설계자는 다양한 프로세서 기술과 IC 기술 간의 균형을 맞춰야 합니다. 일반적으로 프로세서 기술은 IC 기술과 아무런 관련이 없습니다. 즉, 모든 프로세서 기술은 모든 IC 기술을 사용하여 구현할 수 있지만 최종 장치의 성능, NRE 비용, 전력 소비, 크기 및 기타 지표는 매우 그림 12-21과 같이 다릅니다.
더욱 다양해진 프로그래밍 가능 기술은 뛰어난 유연성을 제공하고 NRE 비용을 절감하며 제품 프로토타입 및 출시 시간을 단축합니다. 맞춤형 기술은 대량 생산을 위해 더 낮은 전력 소비, 더 나은 성능, 더 작은 크기 및 더 낮은 비용을 제공할 수 있습니다.
일반적으로 기업이 셋톱박스, 홈라우터, 범용프로세서 등의 제품을 출시하고자 할 때 먼저 반맞춤형 제품을 출시해 최대한 빠르게 시장을 선점한 뒤, 완전 맞춤형 제품. 또한 먼저 보다 안정적인 기존 기술을 사용하여 프로세서를 구현한 다음 새로운 프로세스 기술을 사용하여 차세대를 구현할 수도 있습니다. 마찬가지로, 임베디드 시스템 설계자는 프로그래밍 가능 장치를 사용하여 프로토타입을 제작하여 출시 시간을 단축한 다음 대량 생산을 위해 맞춤형 장치를 사용할 수 있습니다. 이러한 원칙을 바탕으로 설계자는 프로세서 기술과 사용되는 프로세서에 대해 합리적인 선택을 할 수 있습니다. 일반적으로 완전히 사용자 정의가 가능하고 상업적으로 이용 가능한 "범용 프로세서 소프트웨어"는 대부분의 상황에 적합한 옵션입니다.
(2) 일반 임베디드 프로세서의 선택. 사용자와 프로젝트의 요구에 따라 적합한 범용 임베디드 프로세서를 선택하십시오. 선택 시 다음 지표를 고려해야 합니다.
프로세서 속도. 프로세서의 성능은 클록 주파수, 내부 레지스터 크기, 명령어가 모든 레지스터를 동일하게 처리하는지 여부 등 다양한 요소에 따라 달라집니다. 프로세서가 필요한 많은 임베디드 시스템 설계의 경우 목표는 가장 빠른 프로세서를 선택하는 것이 아니라 작업을 완료할 수 있는 프로세서와 I/O 하위 시스템을 선택하는 것입니다. 프로세서의 성능은 시스템 요구 사항을 충족하고 어느 정도 여유가 있지만 너무 높게 선택할 필요는 없습니다. 기술 지표. 현재 많은 임베디드 프로세서는 주변 장치의 기능을 통합하여 칩 수를 줄여 전체 시스템의 개발 비용을 절감합니다. 개발자가 가장 먼저 고려하는 것은 시스템에 필요한 하드웨어 중 일부를 과도한 조합 논리 없이 프로세서에 연결할 수 있는지 여부입니다. 둘째, DMA 컨트롤러, 메모리 관리자, 인터럽트 컨트롤러, 직렬 장치, 시계 등과 같은 프로세서의 일부 지원 칩을 고려하십시오. 개발자가 프로세서에 대해 잘 알고 있다는 것은 프로젝트 개발자가 프로세서 자체의 비용과 개발 비용 사이에서 절충점을 찾아야 함을 의미합니다.
프로세서의 I/O 기능이 시스템의 요구 사항을 충족하는지, 즉 많은 프로세서가 칩 수를 줄이고 비용을 절감하기 위해 내장된 외부 장치를 제공하는지 여부를 최대한 고려해야 합니다. 프로세서 관련 소프트웨어 지원 도구, 즉 프로세서가 임베디드 운영 체제, 프로그래밍 언어 및 개발 도구 등을 완벽하게 지원하는지 여부입니다.
프로세서의 디버깅은 프로세서가 JTAG, BDM 및 기타 디버깅 방법을 지원하는지 여부와 같은 디버깅 기능을 통합했는지 여부를 나타냅니다. 프로세서 제조업체는 신뢰성을 지원합니다. 제품 수명 주기 동안 특정 프로세서를 선택할 때 설계자는 해당 프로세서가 충분한 공급, 기술 지원 등을 갖추고 있는지 확인해야 합니다. 프로세서의 낮은 전력 소비.
임베디드 마이크로프로세서의 가장 크고 가장 빠르게 성장하는 시장은 휴대용 장치, 전자 메모장, PDA, 휴대폰, GPS 내비게이터 및 스마트 가전 제품과 같은 소비자 전자 제품입니다. 저전력 소비. 많은 CPU 제조업체가 이미 이 분야에 진출했습니다.
(3) 하드웨어 설계상의 주의사항. 먼저, 하드웨어를 구성 요소나 모듈로 나누고 구성 요소나 모듈 연결의 블록 다이어그램을 그립니다. 둘째, 각 모듈을 개선하고 시스템을 독립적으로 구현할 수 있는 보다 관리하기 쉬운 부분으로 나눕니다. 일반적으로 시스템의 일부 기능은 소프트웨어와 하드웨어 모두에서 구현될 수 있습니다. 설계자가 소프트웨어 및 하드웨어 기능 할당을 결정하도록 안내하는 통일된 방법은 없지만 성능과 비용 간의 균형은 다음을 기준으로 이루어질 수 있습니다. 제약 목록. 소프트웨어와 하드웨어 사이의 인터페이스를 디자인할 때 하드웨어 디자이너와 소프트웨어 디자이너는 함께 작업하여 이를 완성해야 합니다. 좋은 인터페이스 디자인은 하드웨어를 간단하고 쉽게 프로그래밍할 수 있도록 보장합니다. 설계 시 다음 사항에 유의해야 합니다.
즉, 하드웨어 설계자는 소프트웨어 설계 및 개발을 촉진하기 위해 소프트웨어 설계자에게 점점 더 자세한 정보를 제공해야 합니다.
삼.소프트웨어 하위 시스템 설계
요구사항 분석 단계의 사양 문서에 따라 시스템 계산 모델을 결정하고 소프트웨어 부분의 합리적인 설계를 수행합니다.
(1) 운영 체제 선택. 임베디드 운영 체제를 선택할 때는 다음과 같은 여러 측면을 고려해야 합니다.
운영 체제 기능. 프로젝트에 필요한 운영 체제 기능을 기반으로 운영 체제 제품을 선택하십시오. 시스템이 운영 체제의 기능 전체 또는 일부를 지원하는지, 파일 시스템을 지원하는지, 인간-기계 인터페이스를 지원하는지, 실시간 시스템인지 여부를 고려하십시오. 아니면 시분할제인지, 그 제도를 축소할 수 있는지 등등.
지원 개발 도구 선택. 일부 실시간 운영 체제(rtos)는 시스템 공급업체의 개발 도구만 지원합니다. 즉, 운영 체제 공급업체로부터 컴파일러, 디버거 등도 구해야 합니다. 일부 운영 체제는 널리 사용되고 타사 도구도 사용할 수 있으므로 선택의 폭이 더 넓습니다. 운영 체제를 이식하는 것이 얼마나 쉬운가요? 운영 체제에서 하드웨어로의 포팅은 중요한 문제입니다. 전체 시스템이 일정대로 완료될 수 있는지 여부와 관련된 핵심 요소이므로, 운영체제를 하드웨어로 포팅하는 데 따른 다양한 어려움을 피하고 개발 진행을 가속화하기 위해서는 이식성이 높은 운영체제를 선택해야 합니다. 시스템의. 운영 체제의 메모리 요구 사항은 무엇입니까? 운영 체제의 더 큰 메모리 요구 사항을 충족하기 위해 추가 RAM 또는 eeprom이 필요한지 고려하십시오. 일부 운영 체제에는 대상별 메모리 요구 사항이 있습니다. tornado/vxworks와 같이 개발자는 운영 체제에 리소스를 할당하는 대신 애플리케이션 요구 사항에 따라 필요한 리소스를 할당할 수 있습니다. 개발자는 수 킬로바이트의 메모리가 필요한 임베디드 설계부터 더 많은 운영 체제 기능이 필요한 복잡한 고급 실시간 애플리케이션에 이르기까지 최대 80가지의 다양한 구성 중에서 선택할 수 있습니다.
운영 체제 추가 기능 패키지. 네트워크 프로토콜 스택, 파일 시스템, 일반적으로 사용되는 다양한 주변 장치용 드라이버 등과 같은 필수 소프트웨어 구성 요소가 포함되어 있는지 여부 운영 체제는 얼마나 실시간입니까? 실시간은 소프트 실시간과 하드 실시간으로 구분됩니다. 일부 임베디드 운영 체제는 소프트 실시간 성능만 제공할 수 있습니다. 예를 들어 Microsoft Windows CE 2.0은 대부분의 임베디드 및 비임베디드 요구 사항을 충족할 수 있는 32비트, Windows 호환 마이크로커널, 확장 가능한 실시간 운영 체제입니다. 응용 프로그램.그러나 실시간 성능은 충분히 강력하지 않으며 소프트 실시간 임베디드 작업입니다.
운영 체제. 운영 체제는 얼마나 유연합니까? 운영 체제를 맞춤화할 수 있는지, 즉 시스템 기능을 실제 필요에 따라 맞춤화할 수 있는지 여부입니다. 일부 운영 체제에는 임베디드 Linux, tornado/vxworks 등과 같은 강력한 조정 기능이 있습니다.
(2) 프로그래밍 언어 선택. 프로그래밍 언어를 선택할 때 다음과 같은 여러 측면도 고려해야 합니다.
다재. 마이크로프로세서 기술이 지속적으로 발전함에 따라 그 기능은 점점 더 전문화되고 유형도 점점 더 많아지고 있습니다. 그러나 다양한 유형의 마이크로프로세서에는 고유한 전용 어셈블리 언어가 있습니다. 이는 시스템 개발자에게 큰 장애물을 설정하여 시스템 프로그래밍을 더욱 어렵게 만들고 소프트웨어 재사용을 불가능하게 만듭니다. 일반적으로 고급 언어는 특정 기계의 하드웨어 구조와의 접촉이 적습니다. 대부분의 마이크로프로세서에 사용할 수 있습니다. 우수한 지원과 다양한 기능을 제공합니다.
이식성. 어셈블리 언어는 특정 마이크로프로세서와 밀접하게 연관되어 있기 때문에 특정 마이크로프로세서용으로 설계된 프로그램을 다른 유형의 마이크로프로세서에 직접 이식할 수 없기 때문에 이식성이 떨어집니다. 고급 언어는 모든 마이크로프로세서에 공통되므로 프로그램은 다른 마이크로프로세서에서 실행될 수 있고 이식성이 더 높습니다. 이것이 소프트웨어 재사용의 기초입니다. 유효성. 일반적으로 언어 수준이 높을수록 컴파일러와 오버헤드가 커지고 애플리케이션이 더 커지고 느려집니다. 그러나 어셈블리 언어와 같은 저급 언어에만 의존하여 애플리케이션을 개발하면 복잡한 프로그래밍과 긴 개발 주기 등의 문제가 발생합니다. 따라서 개발 시간과 런타임 성능 간에는 상충 관계가 있습니다.
유지 관리성. 어셈블리 언어와 같은 저수준 언어는 유지 관리가 불가능합니다. 고급 언어 프로그램은 모듈식으로 설계되는 경우가 많으며 각 모듈 간의 인터페이스는 고정되어 있습니다. 따라서 시스템에 문제가 발생했을 때 특정 모듈에서 문제를 빠르게 찾아 신속하게 해결할 수 있다. 또한, 모듈형 설계는 시스템 기능의 확장 및 업그레이드를 용이하게 합니다.
기본 성능. 임베디드 시스템의 개발 과정에서 사용되는 언어 유형에는 Ada, C/C++, Modula-2, Java 등이 있습니다. Ada 언어는 엄격하게 정의되어 있고 읽기 쉽고 이해하기 쉬우며 풍부한 도서관 프로그램 지원을 갖추고 있습니다. 현재 국방, 항공, 우주항공 및 기타 관련 분야에서 널리 사용되고 있으며 앞으로도 이 분야에서 중요한 위치를 차지할 것입니다. 미래. C 언어는 광범위한 라이브러리 프로그램을 지원하며 임베디드 시스템에서 가장 널리 사용되는 프로그래밍 언어입니다. 앞으로도 오랫동안 임베디드 시스템 애플리케이션 분야에서 중요한 위치를 차지할 것입니다. C++는 GNU C++와 같은 임베디드 시스템 설계에도 널리 사용되는 객체 지향 프로그래밍 언어입니다. Visual C++는 시각적 프로그래밍을 지원하는 통합 개발 환경으로 GUI 프로그램 개발에 널리 사용됩니다. 그러나 C++에 비해 C++의 대상 코드는 더 크고 복잡한 경우가 많습니다. 임베디드 시스템 애플리케이션에서는 이 요소를 충분히 고려해야 합니다.
(3) 소프트웨어 개발 프로세스. 임베디드 소프트웨어의 개발 프로세스는 일반적인 일반 소프트웨어의 개발 프로세스와 다르며 주로 다음 단계를 포함합니다.
(4) 소프트웨어 개발 문서. 임베디드 제품의 개발 및 설계 과정에서 개발 단계에서는 시스템 제품의 구현이 완료되며, 이 단계에서는 제품 설계 및 유지 관리를 완료하는 데 매우 중요한 문서가 필요합니다. , 기술업무 등 문서, 기술계획보고서, 제품사양, 기술조건, 설계지시서, 시험보고서, 요약보고서 등
일반적으로 임베디드 시스템 테스트는 주로 소프트웨어 테스트, 하드웨어 테스트 및 단위 테스트의 세 부분으로 구성됩니다. 일반 시스템 하드웨어 테스트에는 신뢰성 테스트와 전자기 호환성 테스트가 포함됩니다. 현재 전자기 호환성에 대한 필수 국내 및 국제 표준이 있습니다.
임베디드 시스템 소프트웨어의 테스트 방법 및 원리는 기본적으로 일반 소프트웨어의 테스트와 동일하며, 일반적으로 소프트웨어를 테스트할 때 테스트 인스턴스 또는 테스트 시퀀스의 두 가지 소스가 필요합니다. 하나는 사용자가 설계한 것이고 다른 하나는 소스입니다. 표준 테스트 시퀀스입니다. 어떤 종류의 테스트 인스턴스라도 높은 확률로 더 많은 오류를 찾을 수 있어야 하는데, 테스트 내용에는 다음과 같은 차이가 있습니다.
(1) 임베디드 소프트웨어는 오랫동안 안정적으로 동작해야 합니다.
(2) 임베디드 소프트웨어는 일반적으로 빈번한 버전 업그레이드를 거치지 않습니다.
(3) 임베디드 소프트웨어는 일반적으로 중요한 애플리케이션에 사용됩니다.
(4) 임베디드 소프트웨어는 임베디드 하드웨어와 함께 제품의 고장 및 신뢰성에 대한 책임을 져야 합니다.
(5) 실제 조건은 비동기적이고 예측이 불가능하므로 시뮬레이션 테스트가 매우 어렵습니다.
이러한 차이점으로 인해 임베디드 시스템 소프트웨어 테스트는 주로 다음 네 가지 측면에 중점을 둡니다.
(1) 실시간과 동시성을 동시에 만족시키기 어렵기 때문에 대부분의 테스트는 실시간 테스트에 중점을 두고 있다.
(2) 대부분의 실시간 시스템에는 리소스 제약이 있으므로 더 많은 성능 및 유용성 테스트가 필요합니다.
(3) 전용 실시간 추적 도구를 사용하여 코드 범위를 테스트할 수 있습니다.
(4) 신뢰성 테스트 수준은 일반 소프트웨어에 비해 훨씬 높습니다.
또한, 성능 테스트 역시 임베디드 시스템을 설계할 때 완료해야 하는 가장 중요한 테스트 활동 중 하나이며, 임베디드 시스템에 결정적인 영향을 미칩니다.
임베디드 시스템의 특수한 특성으로 인해 시스템에는 다양한 하드웨어 플랫폼과 소프트웨어 플랫폼이 있으며 각 플랫폼은 서로 다른 애플리케이션을 위해 특별히 설계되었습니다. 따라서 애플리케이션 소프트웨어는 다양한 플랫폼 간에 보편적이지 않으며 임베디드 시스템의 업데이트 속도도 상대적으로 빠릅니다. 기존 투자를 보호하고 기존 소프트웨어 자원을 최대한 활용하며 제품 개발 속도를 높이기 위해 임베디드 분야에서는 소프트웨어 이식이 매우 빈번해졌습니다.
그는 30년 이상 기술 연구에 전념해 왔으며, java, linux, javascript, php, css 등 다양한 언어에 능숙하며, 오픈 소스 분야에 많은 공헌을 했습니다. 나중에 참조할 수 있도록 기술 개발의 일부 문제를 공유하는 개발자 문서 스테이션입니다.
우편메소피아@프로톤메일.com