hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
위피
위피(Wireless Internet Platform for Interoperability; WIPI)는 대한민국의 표준 모바일 플랫폼의 이름이다. 통신사간의 모바일 플랫폼을 표준화함으로써, 하나의 콘텐츠를 여러 통신사에서 서비스할 수 있도록 하기 위해 제정되었다.
WIPI는 자바 (MIDP 2.0)와 C 언어를 모두 지원하며 이용한 언어에 따라서 자바로 생성한 콘텐츠를 Jlet, C로 생성한 콘텐츠를 Clet이라고 한다. 바이너리 형식에 대한 호환성은 제공하고 있지 않으며, 프로그래밍 모델과 API에 대한 표준만을 정의하고 있다. WIPI 1판에서는 별도의 자바 규격을 채택하였으나, 현재 사용되는 2판에서는 MIDP2.0 규격을 채택하고 있다.
위피 역사와 활용
2001년 7월 14일, KWISF(한국무선인터넷표준화포럼)에 모바일플랫폼특별분과가 신설되면서 시작되었다. 대한민국 내 이동통신사들의 요구사항을 받아들여 2002년 3월 28일 첫 버전인 WIPI v1.0이 채택되었으며, 2004년 2월 11일 WIPI 2.0판이 발표되었다. 현재 상용화된 최신 버전인 WIPI 2.1.1판은 2006년 11월 27일에 발표되었고, 2008년 기준으로 WIPI 3.0이 개발 중에 있다.
WIPI가 도입되기 이전, 대한민국의 이동통신시장에서는 이동통신사 별로 각각 다른 플랫폼을 사용하고 있었다. 이러한 여러 플랫폼들의 난립이 시장에 의해 통합되지 않으리라는 판단에 정부가 강력한 규제를 걸어 표준 플랫폼을 개발하고, 이를 법을 통해 의무화 하기로 하였다. 이 바탕에는 다음의 의도가 있었던 것으로 해석된다.
위피 역사와 활용
이동통신사별로 각각 다른 플랫폼을 도입하여 사용하다보니, 서로 플랫폼이 호환되지 않는 결과를 가져왔다. A통신사의 플랫폼에 맞추어 개발된 게임 등의 프로그램을 B통신사에서도 제공하기 위해선 개발 인력의 추가 투입 등, 막대한 비용이 필요하게 되었다. 따라서 콘텐츠 개발사들은 시장점유율이 높으며, 보다 많은 수익을 기대할 수 있는 플랫폼에만 선택적으로 서비스를 제공하려는 태도를 취하게 되었다.
심지어는 한 이동통신사에서 여러 가지의 플랫폼을 사용하고 있을 경우, 서비스 대상을 더욱 한정하거나 개발 비용을 더 투자해야 하는 경우도 있었다.
이에 단일 플랫폼을 도입하게 되면, 한 번 개발된 프로그램은 모든 이동통신사를 통해 제공할 수 있게 되므로, 개발비용을 절약할 수 있었다.
위피 역사와 활용
당시 50%가 넘는 시장 점유율을 가지며, 프리미엄 브랜드 정책을 펼치던 SK 텔레콤은 이러한 의도에서 WIPI에 대해 부정적인 태도를 취했던 것으로 알려져 있다. 이동통신시장에서 콘텐츠를 개발하려면 사용자가 가장 많은 SK 텔레콤에서 사용할 수 있도록 개발하는 것이 보다 많은 소비자를 대상으로 제공할 수 있기 때문에 수익률도 올라가기 때문이다.
반면, 상대적으로 콘텐츠 부족에 시달리던 점유율 최하위의 LG 텔레콤은 같은 이유로 WIPI 도입을 반겼던 것으로 알려져 있다. 이용자가 가장 적었던 LG 텔레콤 입장에서는 차후 SK 텔레콤용으로 개발되는 WIPI 플랫폼 콘텐츠들을 흡수하여 보다 많은 콘텐츠를 확보하기를 바랐으리라 짐작할 수 있다.
현재 WIPI는 어느 정도 이러한 목적을 달성하였다. 단, WIPI 개정본 관리의 오탈자 및 사소한 실수, 그리고 구현 방법의 차이로 인해 각 이동통신사별로 프로그램을 조정해주어야 한다.
위피 역사와 활용
대한민국 정부 주도로 시작된 WIPI는 초기에 외산 플랫폼에 대한 로열티 지급을 막겠다는 의도가 포함되어 있었다. 퀄컴사의 BREW와 썬 마이크로시스템즈의 J2ME 플랫폼으로 인한 로열티 지급을 국산 플랫폼으로 대체하면 상당한 외화 지출을 막을 수 있다는 계산이었다.
퀄컴사에서는 정부차원의 규제가 자유로운 시장 경쟁을 막는다 하여 한국과 미국 정부에 이러한 규제를 풀어줄 것을 요청했고, 이로 인해 한미 FTA협상에도 영향을 끼쳤던 것으로 알려져 있다.
또한, BREW 플랫폼을 계속 사용하기 위해 WIPI on BREW, BREW on WIPI 등의 방법을 계속 모색하고 있다.
상대적으로 비전문가의 입장인 정부에서 강제적으로 시행한 정책에 이동통신사와 단말개발사의 미온적인 참여로 표준이 발표되고 시장에 출시된 이후, 뒤늦게 WIPI의 상당부분이 썬 마이크로시스템즈의 특허를 침해하고 있다는 사실이 밝혀졌다. 결국, 썬 마이크로시스템즈에 로열티를 내는 것은 피할 수 없게 되었고, 이는 WIPI에 대해 부정적인 시각을 부각시키는 이유 중 하나로 꼽히게 되었다.
프로그래밍 언어라는 측면으로 볼 때, 대한민국 내의 모바일 플랫폼은 C언어와 Java언어로 나눌 수 있다. 이에 WIPI는 어느 한 특정 언어만 사용하는 것이 아니라 양쪽 모든 언어를 지원하는 것을 목표로 삼았다. 플랫폼 구현의 측면에서는 C언어와 Java언어에 각각 API를 제공하고, 이를 다시 추상화 계층인 HAL을 통해 서비스 하는 디자인을 사용하였다. 프로그램의 개발이라는 측면에서는 C언어와 Java로 언어로 만든 프로그램의 중간 결과물을 COD(Compile On Demand) 서버를 통해, 서비스할 대상의 이동 통신 단말에 맞추어 최종 결과물을 만드는 방식을 채택하였다.
현재 WIPI는 공식적으로 C언어와 Java언어를 모두 지원한다. 하지만, 이동통신사에 따라 일부 기능은 C언어에서만 지원 하는 등의 제약을 가지고 있다. 또한, 플랫폼 구현은 각 이동통신사에 따라 COD를 사용하지 않는 경우도 있다.
위피 현재
WIPI의 애초 목표중 하나는 대한민국 내 이동통신시장에 단일 플랫폼 제공이었다. 이는 해외 시장이 전 세계적으로 BREW와 J2ME라는 플랫폼을 기반으로 하고 있는 것에 비해, 좁은 대한민국 내 시장에 3개 이동통신사가 5개 이상의 플랫폼을 사용하고 있는 비효율에 대한 개선사항이라 할 수 있다. 또한, 단일 플랫폼을 사용함으로써 중복되는 콘텐츠들에 대한 개발시간을 많이 줄일 수 있을 것을 기대하였다. 하지만 WIPI라는 플랫폼 자체가 애초의 의도와는 다르게, J2ME 플랫폼과의 유사성으로 인해 추가적인 로열티 지출이 불가피하게 되었다. 아이러니컬하게도, 이는 WIPI플랫폼으로 개발된 콘텐츠를 J2ME 플랫폼으로 재개발하거나, J2ME 플랫폼에서 개발된 콘텐츠를 WIPI로 재개발하는데 소요되는 시간을 단축시키는 결과를 가져왔다. 단일 각 구현사의 실수 및 이동통신사의 잘못된 정책으로 인해 WIPI API의 차이점 및 동작 자체도 불완전하게 구현된 부분이 발생하였다. 이로 인해 동일한 플랫폼임에도 불구하고 다른 이동통신사로 콘텐츠를 변환할 때 개발 자원의 소요가 발생하게 된다. 하지만 이는 이전의 타 플랫폼으로 재개발할 때 드는 자원 소요에 비하면 상당한 개발 자원의 절감을 가져왔다는 평가를 받고 있다.
위피 현재
이통3사 별로 WIPI를 적용하는 전략에 있어 큰 차이를 보이고 있다. KTF 및 LGT는 WIPI Java를 중심으로 하는 콘텐츠 구동 플랫폼으로 사용한데 비해 SKT는 WIPI를 자사의 서비스 플랫폼으로 사용하였다. WIPI를 사용해서 SKT의 주요 부가서비스를 구현하고, 이를 제조사에게 포팅 요청을 하는 전략을 사용하였다.
따라서 SKT의 WIPI는 타사와는 달리 부가서비스와 관련된 특수한 API를 다수 포함하고 있다. 물론 이러한 API는 일반 개발자들에게는 공개되어있지 않다. 이러한 전략은 시간이 갈수록 SKT 만의 WIPI 규격을 추가하게 되었으며, 국내 제조사의 경우에는 지속적으로 추가 규격을 구현한 반면, 외국 제조사가 국내에 단말을 출시하고자 할 때 커다란 장벽이 되어버렸다.
SKT 통합 메시지함이 그 대표적인 경우로서, 해당 서비스를 제조사가 적용하려면 SKT 확장 WIPI API를 모두 구현해야 하는데, 다년간 누적된 히스토리 없이 이를 단기간에 구현하는 것에 큰 부담을 느낀 외국 업체들이 결국 한국시장을 한동안 포기하도록 하는데 큰 원인이 되었다.
위피 현재
대한민국 방송통신위원회의 2009년 4월 1일부터 탑재 의무화 해제를 결정하였다.WIPI 탑재 의무화 해제 결정에 따라, 한국 휴대전화 시장의 개방은 더욱 가속화되어 경쟁이 치열해질 것으로 전망된다. 이 결정에 한국 대형 통신업체들과 휴대전화 소비자들은 환영하는 반면, 한국 무선 소프트웨어 및 콘텐츠 업체들은 당혹스러워하고 있다. 결정으로 인하여 대한민국 최초의 스마트폰인 아이폰 3GS가 국내에 정식 출시가 되었고 그 후 현재까지 수 많은 스마트폰이 출시되었다.
위피 구현
LG전자의 SD1100, 삼성전자의 SCH-X430이 최초로 WIPI 플랫폼이 탑재되어 시험되었다. 아로마 소프트에서 참조 구현 플랫폼을 구현하였다.
엠페이지에서 WIPI 규격 인증 도구를 개발하였으며, 필링크에서 플랫폼 지원 도구를 개발하였다. 지어 소프트에서 COD(Compile On Demand) 서버를 개발하였다.
WIPI-C는 이노에이스, WIPI-Java는 XCE에서 담당하고 있다. LG SD230 모델이 첫 상용화 단말이다. 특징은 COD를 거치지 않고, C, Java별로 각각 최종 프로그램을 생성하면 이동 통신 휴대 단말에서 이를 실행한다는 것이다.
지어소프트와 엑스로드(지오텔)이 담당하고 있다.
유비벨록스(주)에서 담당하고 있다.
위피 해외 진출
2007년 4월 18일, OMTP와 한국무선인터넷 표준화 포럼은 모바일 플랫폼 표준화 협력을 주 내용으로 하는 양해각서(MOU)를 체결했다.
마사다
마사다(히브리어 מצדה, , 요새라는 뜻)는 이스라엘 남부, 유대 사막 동쪽에 우뚝솟은 거대한 바위 절벽에 자리잡은 고대의 왕궁이자 요새를 말한다.
73년 제1차 유대-로마 전쟁 당시 끝까지 로마군에 항거하던 유대인 저항군이 로마군의 공격에 패배가 임박하자 포로가 되지 않기 위해 전원 자살한 것으로 유명하다. 현재 유네스코가 지정한 세계문화유산 중에 하나이며 유명한 관광지가 되었다.
마사다 개요
사해 서쪽해안에 위치한 천혜의 절벽요새이다. 높이 400m, 정상은 길이 600m, 폭 250m의 평지를 이루고 있다. 마사다는 헤롯왕의 요새인 동시에 유대인들이 로마에 항거했던 유대 전쟁 최후의 비극적 격전지로 유명하다. 1963 ∼1965년 고고학자 이갈 야딘 교수의 발굴작업으로 그 실체가 알려지게 되었다.
서기 70년 로마제국의 티투스 장군이 예루살렘을 공격해오자, 유대인 지도자 엘리아젤 벤 야이르가 이끄는 유대인 열심당원(Zealot 또는 Kanai)들 약 960명이 마사다 요새로 피신하여 로마에 대한 저항운동을 계속하였다. 그러자 로마군단은 마사다의 험난한 지형 때문에 쉽게 정벌하지 못하고 장장 3년 동안이나 공격을 계속해 오던 끝에 엄청난 토담을 쌓아 마사다 요새에 접근한다.
마사다 개요
이로써 마사다의 수비벽이 무너지고 로마군단의 진격이 확실시되자 지도자 벤야이르는 로마군에 잡혀서 온갖 수모를 겪느니 차리리 자유인으로서 영광되게 죽기를 결심한다. 각 가족의 가장들은 사랑하는 아내와 자식들을 직접 칼로 찔러 죽인 다음 모든 남자들이 한 자리에 모여 열 명을 추첨하고 그들이 나머지 사람들을 죽이고 다시 한 명을 뽑아 아홉 명을 죽인 후 그도 최후로 자결하였는데, 요새푸스의 유대전쟁사에 의하면 노파 1명, 어린이 5명, 엘리아젤 벤 야이르의 친척 노인 1명 등 모두 7명이 생존하여 이 이야기가 전해졌다고 한다.
3년 동안 한맺힌 포위작전에 대한 영광의 대가를 바랐던 로마군은 960구의 시체 앞에서 망연자실했으며 그 비극적인 전설같은 사실이 오늘날까지 전승화되고 있어 이스라엘인들의 불멸의 성지가 되었다. 마사다는 현재 이스라엘 장병들의 선서식장으로 활용되기도 한다.
마사다 역사
1세기의 유대인 역사가 요세푸스에 따르면 마사다는 기원전 37년부터 31년 사이에 로마제국의 괴뢰정권인 헤로데 대왕이 악정으로 인해 자기에 대항한 반란이 일어날 것에 대비하여 피난 요새이자 왕궁으로 세웠다고 한다. 그러나 요새로 지어진 것은 하스모니안 왕가의 얀나이우스가 먼저이며 이후 헤롯 대왕의 뛰어난 건축술로 다시 증축한 것이다.수천 명이 몇 년간 충분히 먹을 수 있을 정도 분량의 식량을 쌓을 수 있는 식량창고도 만들었다.
66년 제1차 유대-로마 전쟁이 발발하였다. 일단의 유대인 저항군이 주둔하고 있던 로마수비대를 몰아내고 이 요새를 차지했으며 당시의 지도자는 에리아자르 벤 야이르였다고 한다. 70년 예루살렘이 함락되자, 예루살렘에서 쫓겨난 다른 유대인들과 그 가족이 마사다로 피난해서 합류했으며 2년 동안 이곳을 근거지로 삼고 로마군과 자신의 뜻을 따르지 않은 다른 유대인을 공격했다.
마사다 역사
72년 플라비우스 실바장군이 이끄는 로마 제10군단이 마사다로 진격했다. 여러차례 요새를 공격했으나 성벽은 무너지지 않았고, 이에 로마군은 서쪽의 고원과 같은 높이의 거대한 성채를 쌓아올려 공성을 준비했다. 요세푸스는 그가 기록한 다른 전투와는 달리 이 전투에서 유대 저항군의 반격을 기록하지 않았는데 이는 당시 마사다의 저항군이 로마군에 대항할 전력이 없었기 때문으로 보고 있다. 하지만, 다른 역사학자들은 로마군이 성채를 쌓을 때 같은 열심당인 유대인 노예를 이용했기 때문에 민족주의성향이 다분한 열심당원이 차마 동족을 죽일 수 없었다고 보고 있다.
73년 드디어 공성을 위한 성채가 마련되자 로마군은 공성기를 이용해 성벽일부를 깨뜨리고 요새로 진격해 들어갔다. 그러나 식량창고를 제외한 요새안의 모든 건물이 방화로 불에 탔고 엄청난 수의 자살한 시체들만 즐비했다. 유대인 율법은 유대인의 자살을 엄격히 금지하고 있었기에 유대인들은 제비를 뽑아 서로를 죽였으며, 최후에 2인이 남자 한 명이 죽이고 남은 한 명은 자살했다고 한다. 다른 건물을 모두 불에 태우면서도 식량창고만은 남긴 것은 최후까지 자신들이 노예가 되지 않으려고 자살한 것이지, 식량이 없거나 죽을 수밖에 없어서 자살한 것이 아니라는 것을 보여주기 위한 목적이었다.
마사다에서 살아남은 것은 여자 두 명과 다섯 명의 아이들뿐이며. 로마군은 유대인들의 정신력에 겁을 먹고 그들을 죽이지 않았다고 한다.
마사다 오늘날의 마사다
마사다는 1842년 그 존재가 알려졌고, 1963년부터 1965년까지 이스라엘 고고학자들에 의해 광범위하게 발굴되었다. 거의 2,000년 동안 이 요새가 사람의 손에 닿지 않았던 것은 그만큼 이 곳으로 올라가는 길이 험난하고 어렵기 때문이다. 지금은 관광객의 트래핑을 위한 샛길이 나 있으며 따로 케이블카도 설치되었다.
헤로데 대왕의 두 개의 궁전과 빗물을 저장했던 거대한 수조, 로마식 목욕탕과 유대 반란군의 막사, 창고 등이 발굴되어 복원 되어있고 로마군이 요새를 둘러서 쌓았던 성채와 그 외곽에 로마군 막사의 유적도 발굴되어 있다.
이스라엘 국방군 장관이었던 모세 다이안은 이곳의 고대 전쟁사를 이스라엘 국방군의 상징으로 보고 신병훈련을 마사다에서 끝마치게 했다. 부대에서 이곳까지 명예스러운 행진을 하며 밤에 이곳을 올라 "다시는 마사다가 함락되게 하지 않는다!"는 맹세를 하는 의식을 한다.
2001년 유네스코는 이곳을 세계문화유산으로 지정했다.
NGC 1
NGC 1 (또는 GC 1, UGC 57, PGC 564, Holm 2a)는 페가수스자리 방향으로 지구로부터 약 2억 1,000만~2억 1,500만 광년 떨어져 있는 나선 은하로 형태 분류상 Sbc형에 속한다. 하인리히 루트비히 다레스트가 1861년 9월 30일 발견했다. LEDA 1818016과도 상호 작용하는 지는 의문이다.
NGC 1 관측 역사
1860년 하인리히 루트비히 다레스트는 코펜하겐 천문대에서 11 인치 반사 망원경을 시험하던 중 NGC 1을 발견했다. 이 은하의 발견은 다레스트가 발견한 최초의 심원 천체라는 점에서 더욱 의미가 있다. 그는 NGC 1의 발견을 '희미하고, 작으며, 둥글고, (북쪽과 남쪽에 있는) +11~14 등급 밝기 항성들 사이에 있음'이라고 기술했다. 1866년과 1868년에 헤르만 슐트스도 웁살라에서 9.6 인치 반사 망원경을 이용하여 NGC 1을 관측했다.
당시 다레스트와 슐트스 모두 훨씬 어두운 NGC 2를 발견하지 못했다. NGC 1은 NGC 2와 매우 가까이 붙어 있는 것처럼 보이지만 실제로 두 천체는 멀리 떨어져 있으며 묶여 있지 않다. NGC 2를 발견한 사람은 로렌스 파슨스로 당시 그는 NGC 2를 NGC 1의 '동반 천체'로 생각했다.
NGC 1 상세
NGC 1의 지름은 약 14만 광년으로 추정되어 우리 은하(약 16만 광년)와 크기가 거의 비슷한 것으로 보인다. 겉보기 등급은 13.65에 불과하여 너무 어두워 밤하늘에서 맨눈으로 볼 수 없으나 절대 등급은 -22.08로 우리 은하보다 약 2~3 배 정도로 광도가 높다. NGC 1에서 가장 가까운 이웃 은하는 지름 약 8만 광년 크기의 UGC 69로 둘은 약 400만 광년 떨어져 있다.
NGC 1의 겉보기 크기는 1.6' × 1.2'이다. 형태는 허블 순차와 드 보클레르의 확장된 허블 순차에 따르면 SABbc로 '뚜렷하지 않은 은하핵 막대'와 '헐겁게 감긴 모양의 나선팔' 구조를 보여준다. 중심부 은하의 지름은 약 9만 광년에 불과하지만, 거대하면서 분산 되어 있는 나선팔이 중심부로부터 동쪽으로 확장되어 있으며 이 팔은 과거 은하간 병합 사건으로 생긴 것 같다.
NGC 1 상세
약 0.015177의 적색 편이와 그로부터 나오는 초당 약 4,450 킬로미터의 후퇴 속도에 기반하여 태양계로부터 NGC 1 까지의 거리는 허블의 법칙을 이용하여 계산할 수 있다. 현재의 관측 데이터를 이용하면 지구로부터 이 은하까지의 거리는 약 2억 1,000만 ~ 2억 1,500만 광년이 나오며 이 거리는 적색 편이를 고려하지 않고 구한 예상 거리인 1억 7,500만 ~ 2억 4,500만 광년에 잘 부합된다. NGC 1의 후퇴 속도를 초 당 약 2,215 킬로미터로 구한 측정치에 따르면 이 은하 까지의 거리는 대략 1억 광년으로 줄어든다. 그러나 대다수 천문학자들은 이 값을 신뢰하지 않으며 다른 은하의 값을 잘못 부여한 것이라고 믿고 있다.
NGC 1 천체 목록
NGC 1은 상기 천체 목록의 후속작 신판일반목록에도 첫 번째로 등재되어 있다. 해당 목록을 편집할 당시(원기 1860)의 좌표 상으로 NGC 1은 목록에 수록된 모든 천체들 중 경도가 가장 작아서 그 자체로는 특별히 눈에 띄는 은하가 아님에도 적경 순서에 따라 첫 번째로 수록되었던 것이다. 이후 NGC 1의 좌표는 변화했으며 현재 기준으로 이 은하는 더 이상 NGC 천체들 중 적경이 가장 작은 천체가 아니다.
NGC 1은 웁살라 일반목록과(UGC 57) 주요 은하 목록에도(PGC 564) 실려 있다.
항공전자 소프트웨어
항공전자 소프트웨어(영어: avionics software)는 항공기 구성품에 탑재하기 때문에 안전성과 신뢰성을 요구하는 임베디드 소프트웨어를 말한다.  기존에 임베디드 소프트웨어와 차이는 안전성을 위해 정해진 법칙과 최적화된 소프트웨어 개발 프로세스가 있는 점이다.
소프트웨어 개발 프로세스
소프트웨어 개발 프로세스(software development process)는 소프트웨어 제품을 개발하기 위해 필요한 과정 또는 구조이다. 비슷한 말로 소프트웨어 생명 주기와 소프트웨어 프로세스가 있다. 소프트웨어 개발 프로세스에는 몇 가지 모델들이 존재하며, 이들 각각은 해당 단계별로 요구되는 활동이나 작업을 기술하고 있다.
이반 6세
이반 6세(Иван VI, 1740년 8월 13일 ~ 1764년 7월 15일)는 러시아 제국의 황제(1740년 ~ 1741년)다. 로마노프 왕조의 5번째 군주로, 본명은 이반 안토노비치 로마노프(러시아어: Иоанн Антонович Рома́нов)다.
이반 6세 생애
1740년 8월 13일 안나 이바노브나 여제의 이질녀인 메클렌부르크의 공녀 안나 레오폴도브나와 브라운슈바이크-볼펜뷔텔 공작 안톤 울리히 사이에 태어난 아들로, 이반 5세의 외외증손자다.
1740년 10월 17일 안나의 유언에 따라 러시아의 황제로 선포되었다. 통치기간 동안 섭정자로서 비론이 임명되었다. 그 해 11월 9일에 일어난 미니흐의 혁명 이후 섭정 황제의 모후 안나 레오폴도브나가 새 섭정을 맡았다. 옐리자베타 페트로브나가 귀족들을 이끌고 혁명을 일으킨 결과 1741년 11월 25일에 이반 6세는 제위에서 물러났다. 옐리자베타는 처음에는 이반 6세와 그의 가족들을 독일에 있는 사가로 추방하라는 지시를 내렸으나, 당시 대외적으로 전쟁 중인 시기여서 혼란이 올 가능성이 있었기 때문에 곧 이를 취소해버렸다. 이러한 이유로 모든 가족들이 붙잡혀서 여러 곳을 전전하다가 홀모고르이에 4년 동안 근친들로부터 격리되었다.
이반 6세 생애
16살에 이반 6세는 최종적으로 실리셀부르크 요새로 유폐되었는데, 그의 이름이 그곳의 요새지기에조차 알려지지 않을 정도로 외부 세계와의 어떠한 접촉도 엄격히 금지되었다. 1762년 요새를 방문한 표트르 3세와 예카테리나 2세는 이반 6세의 의식주에 관한 규칙을 엄하게 할 것을 명령했으며, 그를 석방시킬 경우 살려두지 않겠다고 위협했다. 1764년 7월 5일 밤, 육군중위 미로비치가 이반 6세를 탈옥시키려고 했으나 발각되어 이반 6세는 살해되었고 시신은 실리셀부르크 요새에 매장되었다. 감옥에서 태어난 그의 형제자매들은 그의 왕고모인 덴마크의 줄리아나 왕대비의 보호하에 1780년에 덴마크로 보내졌지만 평생 감시를 받았고 정상적인 삶을 영위하지 못했다.
LRU
LRU는 다음과 같은 뜻이 있다.
LRU(Line-replaceable unit) 라인 교체 가능 장치는 비행기, 선박 또는 우주선의 모듈식 구성 요소로 작동 위치에서 신속하게 교체할 수 있도록 설계된 장치이다. 일반적으로 라디오 또는 기타 보조 장비와 같은 밀폐된 장치이며, LRU는 반드시 검은색일 필요는 없음에도 불구하고 때때로 "블랙 박스"로 설명된다.
버스
버스의 뜻은 다음과 같다.
버스(bus)는 자동차를 이용하여, 많은 사람의 운송을 목적으로 하는 대중 교통 수단이다.
버스(birth)는 탄생을 의미한다.
버스(verse)는 시, 운문을 의미한다.
버스 (컴퓨팅)
컴퓨터 구조에서 버스(영어: bus, 역사적으로 데이터 하이웨이 또는 데이터버스, databus, 문화어: 모선)는 컴퓨터 내부 구성 요소 간 또는 컴퓨터 간에 데이터를 전송하는 통신 시스템이다. 여기에는 컴퓨터 하드웨어(예: 전선, 광섬유)와 통신 프로토콜을 포함한 소프트웨어가 모두 포함된다. 본질적으로 버스는 일반적으로 전선, 회로 기판의 트레이스 또는 버스바로 구성된 공유 물리적 경로로, 여러 장치가 통신할 수 있게 해준다. 충돌을 방지하고 질서 있는 데이터 교환을 보장하기 위해 버스는 통신 프로토콜에 의존하여 특정 시간에 어떤 장치가 데이터를 전송할 수 있는지 관리한다.
버스는 역할에 따라 분류되는데, 예를 들어 CPU와 메모리를 연결하는 시스템 버스(내부 버스, 내부 데이터 버스 또는 메모리 버스라고도 함)가 있다. 확장 버스는 주변기기 버스라고도 불리며, 시스템을 확장하여 주변기기를 포함한 추가 장치를 연결한다. 널리 사용되는 버스의 예로는 고속 내부 연결을 위한 PCI 익스프레스(PCIe)와 외부 장치 연결을 위한 USB가 있다.
버스 (컴퓨팅)
현대 버스는 병렬 통신과 직렬 통신을 모두 활용하며, 속도와 효율성을 극대화하기 위해 고급 인코딩 방식을 사용한다. 직접 메모리 접근(DMA)과 같은 기능은 CPU 개입 없이 장치와 메모리 간에 직접 데이터 전송을 허용하여 성능을 더욱 향상시킨다.
버스 (컴퓨팅) 주소 버스
주소 버스는 물리 주소를 지정하는 데 사용되는 버스이다. 프로세서나 DMA 지원 장치가 메모리 위치에 읽거나 쓰려면 주소 버스에 해당 메모리 위치를 지정한다(읽거나 쓸 값은 데이터 버스로 전송된다). 주소 버스의 폭은 시스템이 주소 지정할 수 있는 메모리 양을 결정한다. 예를 들어, 32비트 주소 버스를 가진 시스템은 232 (4,294,967,296)개의 메모리 위치를 주소 지정할 수 있다. 각 메모리 위치가 1바이트를 저장한다면, 주소 지정 가능한 메모리 공간은 약 4 GB이다.
버스 (컴퓨팅) 주소 버스
초기 프로세서는 주소 너비의 각 비트마다 하나의 와이어를 사용했다. 예를 들어, 16비트 주소 버스는 버스를 구성하는 16개의 물리적 와이어를 가졌다. 버스가 넓어지고 길어짐에 따라 이 방식은 칩 핀 수와 보드 트레이스 측면에서 비용이 많이 들게 되었다. Mostek 4096 DRAM부터 멀티플렉서로 구현된 주소 멀티플렉싱이 보편화되었다. 멀티플렉싱된 주소 방식에서는 주소가 교대 버스 사이클에서 두 개의 동일한 부분으로 전송된다. 이렇게 하면 메모리에 연결하는 데 필요한 주소 버스 신호 수가 절반으로 줄어든다. 예를 들어, 32비트 주소 버스는 16개 라인을 사용하여 메모리 주소의 첫 번째 절반을 보낸 다음 즉시 두 번째 절반을 보내는 방식으로 구현할 수 있다.
일반적으로 제어 버스에 있는 두 개의 추가 핀 – 행 주소 스트로브(RAS)와 열 주소 스트로브(CAS) – 는 DRAM에 주소 버스가 현재 메모리 주소의 첫 번째 절반을 보내는지 또는 두 번째 절반을 보내는지 알려주는 데 사용된다.
개별 바이트에 접근하려면 전체 버스 폭(한 워드)을 한 번에 읽거나 쓰는 경우가 많다. 이 경우 주소 버스의 최하위 비트가 구현되지 않을 수도 있다. 대신 제어 장치가 전송된 전체 워드에서 필요한 개별 바이트를 분리하는 역할을 한다. 이는 예를 들어 최하위 비트 두 개가 없어 정렬된 32비트 전송으로 제한되는 VESA 로컬 버스의 경우이다.
역사적으로, 워드만을 주소 지정할 수 있었던 컴퓨터 – 워드 머신도 있었다.
버스 (컴퓨팅) 메모리 버스
메모리 버스는 컴퓨터 시스템에서 주기억장치를 메모리 컨트롤러에 연결하는 버스이다. 원래는 VME버스 및 S-100 버스와 같은 범용 버스가 사용되었으나, 지연 시간을 줄이기 위해 현대 메모리 버스는 DRAM 칩에 직접 연결되도록 설계되었으며, 따라서 JEDEC와 같은 칩 표준 기관에 의해 정의된다. 예로는 다양한 세대의 SDRAM 및 SLDRAM과 RDRAM과 같은 직렬 지점 간 버스가 있다.
버스 (컴퓨팅) 구현 세부 정보
버스는 여러 와이어로 데이터 워드를 병렬로 전달하는 병렬 버스이거나, 비트 직렬 형태로 데이터를 전달하는 직렬 버스일 수 있다. 추가 전원 및 제어 연결, 차동 드라이버 및 양방향 데이터 연결이 추가된다는 것은 일반적으로 대부분의 직렬 버스가 1-Wire 및 UNI/O에서 사용되는 최소 한 개의 도체보다 더 많은 도체를 가진다는 것을 의미한다. 데이터 속도가 증가함에 따라 병렬 버스에서 타이밍 스큐, 전력 소비, 전자기 간섭 및 누화 문제는 점점 더 극복하기 어려워진다. 이 문제에 대한 부분적인 해결책 중 하나는 버스를 이중 펌프하는 것이었다. 종종 직렬 버스는 병렬 버스보다 적은 전기적 연결에도 불구하고 더 높은 전체 데이터 속도로 작동할 수 있는데, 이는 직렬 버스에 본질적으로 타이밍 스큐나 누화가 없기 때문이다. USB, 파이어와이어, 그리고 직렬 ATA가 그 예시이다. 멀티드롭 버스 연결은 고속 직렬 버스에 잘 작동하지 않으므로 대부분의 현대 직렬 버스는 데이지 체인 또는 허브 설계를 사용한다.
병렬 버스에서 직렬 버스로의 전환은 컴퓨터에 사용되는 직렬화기/역직렬화기를 집적 회로에 통합할 수 있게 한 무어의 법칙 덕분에 가능해졌다.
버스 (컴퓨팅) 구현 세부 정보
네트워크 연결(예: 이더넷)은 일반적으로 버스로 간주되지 않지만, 그 차이는 실용적이기보다는 개념적이다. 버스를 특징짓는 데 일반적으로 사용되는 속성은 버스가 연결된 하드웨어에 전원을 공급한다는 점이다. 이는 버스 아키텍처가 스위치 또는 분산 전원을 공급하는 버스바의 기원을 강조한다. 이로 인해 RS-232, 센트로닉스 병렬, IEEE 1284 인터페이스 및 이더넷과 같은 방식은 버스로 제외되는데, 이들 장치 또한 별도의 전원 공급 장치가 필요하기 때문이다. USB 장치는 버스에서 공급되는 전원을 사용할 수도 있지만, 종종 별도의 전원을 사용한다. 이러한 구별은 연결된 모뎀이 있는 일반 전화 서비스(Plain old telephone service) 시스템으로 예시된다. 여기서 RJ11 연결 및 관련 변조 신호 방식은 버스로 간주되지 않으며, 이는 이더넷 연결과 유사하다. 전화선 연결 방식은 신호 측면에서 버스로 간주되지 않지만, 중앙국은 전화 간 연결을 위해 크로스바 스위치가 있는 버스를 사용한다.
버스 (컴퓨팅) 구현 세부 정보
하지만, 이러한 구분(버스에서 전원이 공급된다는 점)은 많은 항공전자 시스템에서는 해당되지 않는다. ARINC 429, ARINC 629, MIL-STD-1553 (STANAG 3838), EFABus (STANAG 3910)와 같은 데이터 연결은 일반적으로 데이터 버스 또는 때로는 데이터버스라고 불린다. 이러한 항공전자 데이터 버스는 일반적으로 여러 라인 교체 가능 항목/장치(LRI/LRU)가 공통의 공유 매체에 연결되어 있다는 특징이 있다. 이들은 ARINC 429처럼 단방향일 수 있다. 즉, 단일 소스 LRI/LRU를 가질 수 있거나, ARINC 629, MIL-STD-1553B, STANAG 3910처럼 이중이며, 연결된 모든 LRI/LRU가 다른 시간(반이중 통신)에 데이터의 송신기 및 수신기로 작동할 수 있다.
버스 (컴퓨팅) 구현 세부 정보
버스의 주파수 또는 속도는 MHz와 같은 Hz 단위로 측정되며, 초당 클록 사이클 수를 결정한다. 클록 사이클당 하나 이상의 데이터 전송이 있을 수 있다. 클록 사이클당 단일 전송이 있으면 SDR(싱글 데이터 레이트)이라고 하고, 클록 사이클당 두 번의 전송이 있으면 DDR(더블 데이터 레이트)이라고 하지만, SDR 이외의 신호 사용은 RAM 이외에서는 흔하지 않다. 이에 대한 예시가 SDR을 사용하는 PCIe이다. 각 데이터 전송 내에는 여러 비트의 데이터가 있을 수 있다. 이는 버스의 폭으로 설명되며, 버스가 클록 사이클당 전송할 수 있는 비트 수이며, 각 도체가 한 번에 한 비트를 전송하는 경우 버스가 가진 물리적 전기 도체의 수와 동의어일 수 있다. 초당 비트 단위의 데이터 전송률은 클록 사이클당 비트 수에 주파수, 그리고 클록 사이클당 전송 수를 곱하여 얻을 수 있다. 또는 PCIe와 같은 버스는 PAM4와 같은 변조 또는 인코딩을 사용하여 2비트를 심볼로 묶어 전송함으로써 버스의 주파수를 늘리지 않고도 데이터 전송 속도를 높일 수 있다. 128/130b(b는 비트) 인코딩과 같이 오류 수정을 허용하는 인코딩의 사용으로 인해 유효 또는 실제 데이터 전송 속도/전송률이 더 낮을 수 있다. 데이터 전송 속도는 대역폭으로도 알려져 있다.
버스 (컴퓨팅) 구현 세부 정보
가장 간단한 시스템 버스는 완전히 분리된 입력 데이터 라인, 출력 데이터 라인, 그리고 주소 라인을 가지고 있다.
비용을 줄이기 위해 대부분의 마이크로컴퓨터는 서로 다른 시간에 입력과 출력에 동일한 와이어를 재사용하는 양방향 데이터 버스를 가지고 있다.
일부 프로세서는 주소 버스, 데이터 버스 및 제어 버스의 각 비트에 전용 와이어를 사용한다.
예를 들어, 64핀 STEbus는 8비트 데이터 버스에 전용된 8개의 물리적 와이어, 20비트 주소 버스에 전용된 20개의 물리적 와이어, 제어 버스에 전용된 21개의 물리적 와이어, 그리고 다양한 전원 버스에 전용된 15개의 물리적 와이어로 구성된다.
버스 멀티플렉싱은 더 적은 수의 와이어를 필요로 하며, 이는 많은 초기 마이크로프로세서 및 DRAM 칩에서 비용을 절감하는 효과가 있었다.
한 가지 일반적인 멀티플렉싱 방식인 주소 멀티플렉싱은 이미 언급되었다.
또 다른 멀티플렉싱 방식은 주소 버스 핀을 데이터 버스 핀으로 재사용하는 것이다. 이는 PCI 버스와 8086에서 사용된 방식이다.
다양한 직렬 버스는 멀티플렉싱의 궁극적인 한계로 볼 수 있는데, 각 주소 비트와 각 데이터 비트를 한 번에 하나씩 단일 핀(또는 단일 차동 쌍)을 통해 전송한다.
버스 (컴퓨팅) 역사
시간이 지남에 따라 여러 그룹의 사람들이 IEEE 버스 아키텍처 표준 위원회(BASC), IEEE 슈퍼버스 연구 그룹, 오픈 마이크로프로세서 이니셔티브(OMI), 오픈 마이크로시스템즈 이니셔티브(OMI), EISA를 개발한 나인 갱 등 다양한 컴퓨터 버스 표준에 대해 연구했다.
초기 컴퓨터 버스는 주기억장치와 주변 기기를 연결하는 와이어 묶음이었다. 초기 호주 CSIRAC 컴퓨터에서는 농담삼아 디지트 트렁크라고 불렸으며, 전기 전력 버스, 즉 버스바의 이름을 따서 명명되었다. 거의 항상 메모리용 버스 하나와 주변 기기용 버스 하나 이상이 별도로 존재했다. 이들은 완전히 다른 타이밍과 프로토콜을 가진 별도의 명령어에 의해 접근되었다.
버스 (컴퓨팅) 역사
첫 번째 복잡한 문제 중 하나는 인터럽트의 사용이었다. 초기 컴퓨터 프로그램은 주변 장치가 준비될 때까지 루프에서 대기하며 I/O를 수행했다. 이는 다른 작업을 수행해야 하는 프로그램에게 시간 낭비였다. 또한, 프로그램이 다른 작업을 수행하려 하면, 다시 확인하는 데 너무 오래 걸려 데이터 손실이 발생할 수 있었다. 따라서 엔지니어들은 주변 장치가 CPU를 인터럽트하도록 조치했다. 인터럽트는 우선 순위가 지정되어야 했는데, CPU는 한 번에 하나의 주변 장치에 대한 코드만 실행할 수 있으며, 일부 장치는 다른 장치보다 시간적으로 더 중요하기 때문이었다.
버스 (컴퓨팅) 역사
고급 시스템은 채널 컨트롤러라는 개념을 도입했는데, 이는 본질적으로 특정 버스의 입출력을 처리하는 데 전념하는 작은 컴퓨터였다. IBM은 1958년 IBM 709에 이를 도입했으며, 이는 해당 플랫폼의 일반적인 특징이 되었다. 컨트롤 데이터 코퍼레이션과 같은 다른 고성능 공급업체들도 유사한 설계를 구현했다. 일반적으로 채널 컨트롤러는 CPU가 다른 곳에서 바쁘다고 알려진 경우 데이터를 이동하는 등 모든 버스 작업을 내부적으로 실행하기 위해 최선을 다했으며, 필요한 경우에만 인터럽트를 사용했다. 이는 CPU 부하를 크게 줄이고 전반적인 시스템 성능을 향상시켰다.
모듈성을 제공하기 위해 메모리 및 I/O 버스는 통합된 시스템 버스로 결합될 수 있다. 이 경우 단일 기계적 및 전기적 시스템을 사용하여 많은 시스템 구성 요소를 연결할 수 있으며, 일부 경우에는 모든 구성 요소를 연결할 수 있다.
버스 (컴퓨팅) 역사
이후 컴퓨터 프로그램은 여러 CPU에 공통된 메모리를 공유하기 시작했다. 이 메모리 버스에 대한 접근도 우선순위를 지정해야 했다. 인터럽트나 버스 접근의 우선순위를 지정하는 간단한 방법은 데이지 체인을 이용하는 것이었다. 이 경우 신호는 물리적 또는 논리적 순서로 버스를 통해 자연스럽게 흐르므로 복잡한 스케줄링이 필요 없게 된다.
디지털 이큅먼트 코퍼레이션(DEC)은 대량 생산되는 미니컴퓨터의 비용을 더욱 절감하고, 주변기기를 메모리 버스에 매핑하여 입출력 장치가 메모리 위치처럼 보이도록 했다. 이는 1969년경 PDP-11의 유니버스에서 구현되었다.
초기 마이크로컴퓨터 버스 시스템은 본질적으로 CPU의 핀에 직접 또는 버퍼 증폭기를 통해 연결된 수동 백플레인이었다. 메모리 및 기타 장치는 CPU 자체가 사용하는 것과 동일한 주소 및 데이터 핀을 사용하여 병렬로 연결되어 버스에 추가되었다. 통신은 CPU에 의해 제어되었으며, CPU는 장치를 메모리 블록처럼 읽고 썼으며, 동일한 명령어를 사용했고, 모든 타이밍은 CPU 속도를 제어하는 중앙 클록에 의해 이루어졌다. 그럼에도 불구하고 장치는 별도의 CPU 핀에 신호를 보내 CPU를 인터럽트했다.
버스 (컴퓨팅) 역사
예를 들어, 디스크 드라이브 컨트롤러는 새로운 데이터를 읽을 준비가 되었음을 CPU에 알리면, CPU는 디스크 드라이브에 해당하는 메모리 위치를 읽어 데이터를 이동했다. 거의 모든 초기 마이크로컴퓨터는 이러한 방식으로 구축되었으며, 앨테어 8800 컴퓨터 시스템의 S-100 버스로 시작되었다.
일부 경우, 특히 IBM PC에서는 유사한 물리적 아키텍처가 사용될 수 있음에도 불구하고, 주변 기기(in 및 out)와 메모리(mov 등)에 접근하는 명령어가 전혀 통일되지 않았고, 여전히 별도의 CPU 신호를 생성하여 별도의 I/O 버스를 구현하는 데 사용될 수 있었다.
이러한 단순한 버스 시스템은 범용 컴퓨터에 사용될 때 심각한 단점을 가지고 있었다. 버스 상의 모든 장비는 단일 클럭을 공유했기 때문에 동일한 속도로 통신해야 했다.
버스 (컴퓨팅) 역사
CPU 속도를 높이는 것이 더 어려워졌는데, 모든 장치의 속도도 함께 증가해야 했기 때문이다. 모든 장치가 CPU만큼 빠르지 않거나 경제적이지 않은 경우, CPU는 대기 상태에 들어가거나 일시적으로 더 느린 클록 주파수에서 작동해야 했다. 컴퓨터 내의 다른 장치와 통신하기 위해서였다. 임베디드 시스템에서는 허용될 수 있었지만, 이 문제는 범용, 사용자 확장형 컴퓨터에서는 오래 용인되지 않았다.
이러한 버스 시스템은 상용 기성 장비로 구성할 때 구성하기가 어렵다. 일반적으로 추가된 각 확장 카드는 메모리 주소, I/O 주소, 인터럽트 우선순위 및 인터럽트 번호를 설정하기 위해 많은 점퍼를 필요로 한다.
버스 (컴퓨팅) 역사
NuBus와 같은 2세대 버스 시스템은 이러한 문제 중 일부를 해결했다. 이들은 일반적으로 컴퓨터를 두 개의 주소 공간으로 분리하여, 한쪽에는 CPU와 메모리, 다른 한쪽에는 다양한 주변 장치를 두었다. 버스 컨트롤러는 CPU 측에서 주변 장치 측으로 이동할 데이터를 받아들여 통신 프로토콜 부담을 CPU 자체에서 덜어주었다. 이를 통해 CPU와 메모리 측이 주변 장치 버스와 별개로 발전할 수 있었다. 버스상의 장치들은 CPU 개입 없이 서로 통신할 수 있었다. 이로 인해 훨씬 더 나은 성능을 얻었지만 카드도 훨씬 더 복잡해졌다. 이러한 버스들은 또한 데이터 경로 크기를 늘려 속도 문제를 해결하는 경우가 많았는데, 1세대에서 8비트 병렬 버스에서 2세대에서는 16비트 또는 32비트로 이동했으며, 플러그 앤 플레이로 나중에 표준화된 소프트웨어 설정을 추가하여 점퍼를 대체하거나 보완했다.
그러나 이러한 새로운 시스템은 이전 시스템과 한 가지 공통점을 가지고 있었다. 즉, 버스에 있는 모든 장치가 동일한 속도로 통신해야 했다. 이제 CPU는 분리되어 속도를 높일 수 있었지만, CPU와 메모리는 통신하는 버스보다 훨씬 더 빠르게 속도를 증가시켰다. 그 결과 버스 속도는 현대 시스템이 필요로 하는 것보다 훨씬 느려졌고, 기계는 데이터 부족에 시달렸다. 이 문제의 특히 흔한 예는 비디오 카드가 PCI와 같은 최신 버스 시스템조차 빠르게 능가했고, 컴퓨터가 비디오 카드 구동을 위해 AGP를 포함하기 시작했다는 점이다. 2004년에는 AGP마저 고성능 비디오 카드와 다른 주변기기에 의해 다시 능가되었고, 새로운 PCI 익스프레스 버스로 대체되었다.
점점 더 많은 외부 장치들도 자체 버스 시스템을 사용하기 시작했다. 디스크 드라이브가 처음 도입되었을 때, 버스에 연결된 카드를 통해 기기에 추가되었기 때문에 컴퓨터에는 버스에 많은 슬롯이 있다. 그러나 1980년대와 1990년대에는 SCSI 및 IDE와 같은 새로운 시스템이 이러한 요구를 충족하기 위해 도입되어, 현대 시스템의 대부분의 슬롯은 비어 있게 되었다. 오늘날 일반적인 기계에는 다양한 장치를 지원하는 약 5가지 다른 버스가 있을 수 있다.
3세대 버스는 약 2001년부터 시장에 등장했으며, 하이퍼트랜스포트와 인피니밴드를 포함한다. 이들은 또한 물리적 연결 측면에서 매우 유연하여 내부 버스로 사용될 뿐만 아니라 서로 다른 기계를 연결하는 데도 사용될 수 있다. 이는 서로 다른 요청을 처리하려고 할 때 복잡한 문제를 야기할 수 있으므로, 이러한 시스템에 대한 작업의 대부분은 하드웨어 자체보다는 소프트웨어 설계에 관한 것이다. 일반적으로 이러한 3세대 버스는 초기 시스템보다 더 높은 프로토콜 오버헤드가 필요하지만, 여러 장치가 동시에 버스를 사용할 수 있도록 허용하면서도 원래 버스 개념보다 네트워크에 더 가깝게 보인다.
위시본과 같은 버스는 오픈 소스 하드웨어 운동에 의해 컴퓨터 설계에서 법적 및 특허 제약을 더욱 제거하려는 시도로 개발되었다.
컴퓨트 익스프레스 링크(CXL)는 고속 CPU-장치 및 CPU-메모리 연결을 위한 개방형 표준 인터커넥트로, 차세대 데이터 센터 성능을 가속화하도록 설계되었다.
버스 (컴퓨팅) 외부 컴퓨터 버스 예시
많은 필드버스는 직렬 데이터 버스이며(시스템 버스 또는 확장 카드의 병렬 데이터 버스 섹션과 혼동하지 말 것), 이들 중 일부는 EIA-485 전기적 특성을 사용한 다음 자체 프로토콜과 커넥터를 지정한다.
다른 직렬 버스:
DO-178B
DO-178B (항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항)는 RTCA 사에 의해 발표된 소프트웨어 개발 표준이다. 이 표준은 RTCA SC-167과 EUROCAE WG-12에 의해 개발되었고, 이를 미국 연방 항공국(FAA)이 항공기 소프트웨어 인증을 위한 용도로 사용할 것을 인정하여 현재 업계에서 상용 항공기이 탑재되는 safety-critical 소프트웨어를 위한 사실 상의(de facto) 표준으로 자리잡았다..
DO-178B 소프트웨어 레벨
안전 평가 프로세스(safety assessment process), 위험도 분석(hazard analysis)으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준으로 삼는 것으로 다음과 같은 단계가 있다.
위와 같은 소프트웨어 레벨에 따라 만족시켜야할 요건의 수와 독립성 수준이 정해진다. 표준에 따르면, "독립성"이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어 있어야 한다는 의미이다..
DO-178B 프로세스와 문서들
소프트웨어 레벨(A에서 D까지, E의 경우에는 DO-178B 상 요건이 없음)에 따른 목표를 만족시키기 위해서는 프로세스가 필요하다. DO-178B에서 프로세스 자체가 구체적으로 명확히 기술되어 있지 않으며 추상적인 수준으로 기술되어 있고, 이를 구체적인 실제 프로젝트에서 실행하는 방법에 대해서는 각 프로젝트 계획 단계에서 이를 계획하도록 되어 있다. 그러므로 실제 프로젝트에서는 구체적인 프로세스를 만족시킨다기보다는 DO-178B의 각각의 요건(objectives)을 만족시키기 위한 활동들이 진행된다. 그리고 사실 그러한 활동이 계획 단계에서 계획된다.
이 프로세스의 결과물들은 다음과 같다.
위에서 시스템 요구사항은 전체 프로젝트의 시작을 위한 일반적인 입력 요구조건이다. 그리고 마지막 세개의 표준서 결과물은 레벨 D에 해당하는 소프트웨어에는 요구되지 않는다.
이 프로세스는 여러 개의 하위 프로세스로 나눌 수 있다.
DO-178B 프로세스와 문서들
개발 프로세스의 산출물은 다음과 같다.
개발시 일반적으로 시스템 요구사항에서 모든 소스 코드 또는 실행가능한 오브젝트 코드로의 추적성이 요구된다.
(요구 수준은 소프트웨어 레벨에 따라 다소 차이가 있다)
일반적으로 적용되는 소프트웨어 개발 프로세스는 다음과 같다.
검증, 형상관리, 품질보증, 인증지원으로 이루어져 있다.
이 프로세스에서 산출되는 문서는 다음과 같다.
이 프로세스를 완료하기 위해서는 모든 코드에 대한 검토 분석 결과와, 시험 및 시험 결과로부터 요구사항으로의 추적성 요건 만족이 일반적으로 요구된다. (소프트웨어 레벨에 따라 요건의 수준은 다소 상이할 수 있음.)
이 프로세스에서는 일반적으로 다음과 같은 도구들을 적용하게 된다.
또한 이 프로세스 내에서 다음과 같은 시험이 수행될 수 있다.
형상 관리 (Configuration Management) 프로세스를 통해 관리, 유지되는 문서들은 다음과 같다.
DO-178B 프로세스와 문서들
이 프로세스를 통해 결함 보고 및 변경과 관련된 활동을 정의하고 통제한다. 형상 관리 프로세스는 일반적으로 다음과 같은 데이터를 보관하고 갱신하는 기능을 수행한다.
품질 보증 (quality assurance) 프로세스에 의한 산출 문서는 다음과 같다.
이 프로세스를 통해 프로젝트 전반에 걸쳐 DO-178B 적합성에 대한 검토(review)와 감사(audit)를 수행한다. 또한 DO-178B 인증 기관인 FAA 또는 이를 위임한 DER에 인증에 필요한 데이터를 제공하는 등의 연결 역할을 수행한다.
일반적으로 미 항공국에서 그 권한을 위임받은 DER (Designated Engineering Representative)이 항공기 제조사 내에 고용되어 인증 절차를 진행한다.
DO-178B 도구 인증(Tool Qualification)
소프트웨어 도구를 사용하면 DO-178B가 요구하는 프로세스를 자동화하고 관리하며 쉽게 적용할 수 있다. DO-178B 기반의 개발 프로젝트에 사용되는 모든 소프트웨어 도구는 인증 프로세스의 부분이다. 따라서 코드를 자동으로 생성하는 개발 도구는 소스 코드와 동일하게 그 개발 도구로서의 인증(qualification)을 보장해야한다. 이는 그러한 개발 도구가 생성한 코드가 최종 항공 시스템에 결함을 발생시킬 수 있기 때문이다. 단 해당 생성 코드에 대해 수동으로 독립적인 검토를 수행할 경우에는 인증 데이터(qualification data)를 제출할 의무는 사라진다. 또한 검증 프로세스에서 소스 코드를 시험/검증하기 위한 도구(시뮬레이터, 시험 실행 환경, 커버리지 분석 도구, 보고서 생성 도구 등)은 대개 소스 코드 자체에 결함을 발생시킬 위험은 낮다. 따라서 검증 도구로서의 적격 검토는 개발 도구의 요건보다는 가벼울 수 있으며, 도구에 대한 동작 요구사항(Tool Operational Requirements) 정의와 그에 대한 시험을 통한 검증을 통해 데이터를 제출한다.
하카타역
하카타역(일본어: 博多駅:はかたえき 하카타에키[*])은 일본 후쿠오카현 후쿠오카시 하카타구 하카타에키추오 가에 있는 큐슈여객철도(JR큐슈), 서일본여객철도(JR 서일본), 후쿠오카시 교통국(후쿠오카시 지하철)의 철도역이다. 규슈철도 개통 때부터 지금까지 존재하는 "규슈에서 가장 오래된 철도역" 중 하나이기도 하다.
하카타역 개요
규슈와 후쿠오카시를 대표하는 터미널 역으로, 규슈 최대의 역이기도 하다. 이 역을 거점으로, 규슈의 주요 도시를 묶는 신칸센, 특급열차나 후쿠오카 도시권 등을 달리는 많은 노선이 발착한다. 2004년 기준으로 특급열차의 발착 개수는 일본에서 제일 많다.
산요 신칸센의 종점이자 도카이도 신칸센, 산요 신칸센의 최서단이기도 하며, 오사카, 나고야, 도쿄 등 혼슈와 연결되는 많은 신칸센 열차가 발착하고 있다. 2011년 3월 12일에는 큐슈신칸센(가고시마 루트)이 이 역까지 연장하여 전 노선 개통과 동시에, 산요 신칸센과 상호 직결 운행을 개시하여, 큐슈신칸센의 기점이 되었다. 또한 도쿄역 이서를 달리는 모든 신칸센 열차(도카이도 • 산요 신칸센 계통의 노조미, 히카리, 고다마 및 산요 • 큐슈신칸센 계통의 미즈호, 사쿠라, 쓰바메)가 정차하는 유일한 역이다.
2007년 3월에 폐점한 하카타 이즈쓰야가 입주하고 있던 당시 역 건물(하카타 스테이션 빌딩)이 해체되어 한큐 백화점이나 도큐 핸즈, 멀티플렉스 시네마 T 조이 등이 입주하는 새 역 건물(JR 하카타 시티)이 건설되어 큐슈신칸센 가고시마 루트 개통 9일 전인 2011년 3월 3일에 개업했다.
하카타역 개요
2013년 10월 15일에는, JR큐슈의 호화 침대 열차인 크루즈 트레인 나나쓰보시 in 규슈가 이 역을 출발해 규슈 각지를 돌아 다니는 운행을 개시했다.
후쿠오카시 지하철의 역은 JR 역의 바로 밑에 있다. 후쿠오카시 지하철의 역 중에서는 덴진 역에 이어 두 번째로 이용자가 많은 거점역이다. 또, 2023년 3월 27일 후쿠오카시 지하철 나나쿠마선이 하카타역까지 연장되었다.
JR 하카타 역의 사무관 코드는 ▲910127, 후쿠오카 시내의 사무관 코드는 ▲919902이다. 또한 후쿠오카 시영 지하철 하카타 역의 사무관 코드는 8551101이다.
JR의 신칸센, 재래선 노선과 후쿠오카 시 지하철 열차가 당역에 정차한다. 지하철 공항선 의역에는 "K11", 지하철 나나쿠마선 의역에는"N18" 이라는 역 번호가 설정되어 있다.
하카타역 개요
신칸센은 JR 서일본의 산요 신칸센의 종점이자. JR큐슈의 큐슈신칸센의 기점이다. 신칸센에 있어서는 당역이 JR 서일본과 JR큐슈의 경계역이다. 신칸센 역의 소속 노선은 산요 신칸센이다. 또한 이 역에서 JR 서일본 하카타종합차량소까지의 회송 선로를 여객영업노선화한 하카타미나미 선의 기점이기도 하다. 단, 하카타미나미 선은 신칸센 승강장에서 발착하고 차량도 신칸센 차량을 사용 중이지만 공식적으로는 재래선에 속한다.
JR큐슈의 역에 정차하는 재래선은 정식으로는 가고시마 본선 뿐이지만, 요시즈카역에서 분기되는 사사구리 선의 열차도 이 역까지 정차하고 있어 이 계통에 후쿠호쿠유타카 선이라는 애칭이 설정되어 있다.
이용 가능 노선 목록을 정리하면 아래와 같다.
하카타역 역사
소재지의 옛 지명인 하카타에서 유래되었다.
"하카타"는 고대 일본, 늦어도 릿코쿠시가 성립된 때부터의 지명이었으며 당나라 시대에는 당나라에 하카타가 하케다이(覇家臺), 핫카쿠시마(八角島) 등의 이름의 무역항으로 알려져 있었다. 명나라의 병법서 우베이지에는 당시 일본에 있던 3개의 항구 중 하나인 "하나아사히토우쓰"로 소개되었고, 에도 시대에는 쿠로다(黒田:일본의 씨족 중 하나)가 나카가와 강 건너편에 세워진 "후쿠오카 성 조카마치"와 함께 번성했다.
하카타 역은 메이지 유신에 이은 문명 개화기였던 1889년, 규슈철도가 규슈 최초의 철도를 부설하는 데 있어 당시의 "하카타"의 최남단에 해당하는 조텐지의 경내 남단을 지나 현재의 데키마치 공원 부근에 세워졌다.
하카타는 다자이후의 외항으로써, 고대부터 번성한 도시였으나, 후쿠오카는 에도 시대 구로다가 영주가 되어 후쿠오카 성을 중심으로 번성한 무가 마을이며, 하카타와 후쿠오카는 나카가와 강을 두고 서로 별개의 도시로 취급되었다.