ОДНОПРОЦЕССОРНАЯ ЭЛЕКТРОННАЯ СИСТЕМА БОРТОВОЙ ДОКУМЕНТАЦИИ 3-ГО КЛАССА Российский патент 2015 года по МПК G06F9/50 G06F21/74 

Перекрестные ссылки на родственные заявки

[0001] Данная заявка заявляет приоритет предварительной заявки США 61/307,012 поданной 23 февраля 2010, и включается в данную заявку посредством ссылки.

Предпосылки к созданию изобретения

[0002] Данное изобретение относится к электронным системам бортовой документации (системам EFB), обеспечивающим вспомогательные компьютерные функции на воздушном судне, и в частности, к системам EFB 3-го класса, постоянно установленным на воздушном судне и пригодным для одновременного содержания и выполнения приложений типа А, В и С.

[0003] Системы EFB являются компьютерными системами, спроектированными, чтобы позволить летному экипажу решать задачи управления полетом легче, эффективнее и с меньшим количеством бумаги. Общая вычислительная платформа системы EFB призвана уменьшить или вытеснить бумажные справочные материалы, такие как руководства по эксплуатации воздушного судна, аэронавигационные карты и другие предметы, которые летный экипаж должен был традиционно приносить на борт воздушного судна в летной сумке пилота. В Соединенных Штатах устройства EFB регламентируются Федеральным Авиационным управлением (FAA) в соответствии с Рекомендательным циркуляром (AC) 120-76A, а в Европе Европейским агентством по авиационной безопасности (EASA) в соответствии с Временным кратким руководством (TGL) 36, включенным в данную заявку посредством ссылки.

[0004] Во многих случаях приложения, спроектированные, чтобы обеспечивать данные, призванные заменить бумажные справочные материалы и отображать их в электронном виде в системе EFB, разрабатывались для использования с операционными системами (ОС) и программными компонентами готовых коммерческих продуктов (COTS), например, ОС Microsoft Windows® со структурными компонентами NET. Примерами этих приложений являются устройства чтения документов, используемые, чтобы отображать на дисплее руководства и справочные документы, программы просмотра конечных карт и электронные бортовые журналы.

[0005] По мере того, как системы EFB развивались и широко распространялись, доступностью дополнительных компьютерных систем с дисплеем в кабине пилота пользовались, чтобы обеспечивать дополнительную функциональность, которая традиционно связывалась с системами основного пилотажного дисплея и многофункциональными дисплеями. Они включают дисплей авиационных данных, связанных с текущим состоянием воздушного судна, включая положение, ориентацию и планирование полета. Эти дополнительные функции в дополнении с традиционными функциями системы EFB делятся на три категории приложений: тип А, В и С. Приложения типа А включают фиксированные представления предварительно составленных данных, традиционно представляемых в бумажном формате (электронные руководства пилота, справочные документы, списки оборудования и руководства по техническому обслуживанию и ремонту). Приложения типа В включают интерактивные приложения, которые могут манипулировать динамическими данными и представлением (карты конечных аэродромов, расчеты характеристик, видео в кабине). Приложения типа С включают элементы, которые, как правило, связаны с основным пилотажным дисплеем и могут влиять на безопасность полета и рабочую загрузку экипажа. Примером приложений типа С является интерактивная подвижная карта, отображающая положение своего судна, или приложение, которое взаимодействует с процессором Системы автоматического зависимого наблюдения (ADS-B), обеспечивающей руководство для Продольных процедур или Сближения и Эшелонирования (M&S), включенных в данную заявку посредством ссылки.

[0006] Согласно АС-120-76А, приложения типа С требуют Проектного разрешения Службы сертификации воздушных судов (AIR), строгость которого обуславливается влиянием, которое может оказать сбой на безопасность и рабочую загрузку экипажа. Комиссия по авиационным радиотехническим средствам (RTCA) публикует DO-178B «Аспекты программного обеспечения в бортовых системах и сертификация оборудования», утвержденное FAA руководство по получению Проектного разрешения для программного обеспечения, используемого в авиационном оборудовании. RTCA,. Inc, это частная, некоммерческая корпорация расположенная в Вашингтоне, округ Колумбия США. DO-178B это один из способов, но не единственный способ, получить проектно-гарантийное разрешение от FAA.

[0007] Согласно АС120-76А, физическому аппаратному обеспечению системы EFB присваивается один из трех классов, исходя из установки и предполагаемого использования. Это классы 1, 2 и 3. Системы EFB 1-го класса, в общем случае, являются системами на коммерческой основе, такими как ноутбук или планшетный ПК, которые являются портативными и не привязаны к воздушному судну. Системы EFB 2-го класса, в общем случае, также являются системами на коммерческой основе и портативными, но подключаются к воздушному судну при нормальной работе. Системы EFB 3-го класса являются установленным авиационным оборудованием и, в отличие от систем EFB 1-го и 2-го класса, должны отвечать нормативным требованиям, предъявляемым в соответствии с их предполагаемой функцией на воздушном судне. RTCA, Inc публикует DO-160F «Внешние условия и методики испытаний для бортового оборудования», одобренное и утвержденное FAA руководство по получению разрешения AIR для аппаратного обеспечения, используемого в авиационном оборудовании, включенное в данную заявку посредством ссылки.

[0008] Приложения типа А и/или В (далее типа А/В) могут назначаться ведущим узлом в системах EFB любого класса и Проектное разрешение для них не требуется. Однако приложениям типа С требуется Проектное разрешение, и могут быть ведущими узлами только в системах EFB 3-го класса, за исключением тех ситуаций, когда приложение имеет Инструкцию по применению технических стандартов (TSO), и когда другие приложения ведущие узлы в системе EFB 1-го класса или 2-го класса, имеют незначительное или никакого влияния на безопасность полетов и не мешают работе приложения типа С с TSO.

[0009] Когда на одной системе EFB 3-го класса ведущие узлы приложения типа А/В и приложения типа С, важно обособить проектно разрешенные приложения типа С и интерфейсы воздушного судна от приложений типа А/В, так чтобы со стороны приложений типа А/В не было отрицательных воздействий или вмешательств в какие-либо критичные с точки зрения безопасности компоненты или программное обеспечение на воздушном судне, подключенное к или размещенное в системе EFB. Текущим способом обособления проектно разрешенного программного обеспечения и защиты компонентов воздушного судна, подключенных к системе EFB, является использование двух отдельный процессоров в пределах одной системы EFB, причем один процессор является ведущим узлом для проектно разрешенной операционной системы, такой как заказная операционная система на базе Linux, и приложений типа С, а второй процессор является ведущим узлом для коммерческой операционной системы, такой как операционная система Windows®, разработанная Microsoft Corporation, Вашингтон, США. Схема, соединяющая два процессора, обеспечивает аппаратный контроль проектно разрешенной операционной системы над коммерческой операционной системой, позволяя контролировать, отслеживать и ограничивать ее работу, чтобы защитить интерфейсы воздушного судна, подключенные к системе EFB. Физическое разделение, обеспеченное двумя отдельными процессорами, обеспечивает достаточную обособленность приложений типа С от приложений типа А/В.

Описание сущности изобретения

[0010] Данное изобретение обеспечивает систему EFB 3-го класса (электронную систему бортовой документации), которая может выполнять приложения как типа А/В, так и типа С на одном процессоре, обеспечивая таким образом существенную экономию по весу, энергопотреблению и стоимости. Определив набор механизмов, посредством которых приложение типа А/В может вмешиваться в выполнение приложения типа С, данные изобретатели реализовали эффекты аппаратной обособленности посредством модификаций операционной системы, ограничивающих доступ к памяти, обработке и ресурсам дисплея. Эти модификации позволяют получить однопроцессорную архитектуру с обособленностью, эквивалентной мультипроцессорной системе.

[0011] В частности, данное изобретение обеспечивает электронную систему бортовой документации 3-го класса, имеющую один процессор, по меньшей мере, с одним ядром и систему электронной памяти, обменивающуюся данными с процессором и хранящую операционную систему. Электронная система бортовой документации обеспечивает сетевой интерфейс, обменивающийся данными с бортовой сетью передачи данных, чтобы подключаться к другому бортовому оборудованию, в том числе навигационным системам и дисплею, который обменивается данными с процессором. Доступ приложений типа А/В в системе электронной памяти, к электронной памяти, дисплею и процессору ограничен согласно заданным правилам, приводимым в исполнение операционной системой, чтобы блокировать потенциальное вмешательство выполнения приложения типа А/В в выполнение приложения типа С.

[0012] Поэтому отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является обеспечение сегрегации между критическими и некритическими приложениями, исполняемыми на одном процессоре, без потребности в отдельных процессорах.

[0013] Операционная система может ограничивать общий размер буферов сокета, используемых для обмена данными, например, путем ограничения общего размера буферов сокета до заранее установленного максимума данных, выделенных на сокет, и путем ограничения общего числа сокетов до заранее установленного максимального числа сокетов. Как в общем понятно в области техники, буферы сокета являются областью хранения в компьютерной памяти, используемой для обмена данными между процессами, выполняемыми компьютером.

[0014] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение избыточного расходования буфера сокета приложениями типа А/В, такие буферы, как правило, находятся в пространстве памяти операционной системы, от сталкивания с операциями операционной системы.

[0015] Операционная система может запрещать сетевые широковещательные сообщения.

[0016] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является обеспечение, чтобы между определенными указанными терминалами были сообщения, которые можно отслеживать, чтобы предотвратить получение доступа обманным путем.

[0017] Система электронной памяти может включать энергонезависимое запоминающее устройство, и каждому приложению может быть присвоен раздел, имеющий полномочие на чтение и выполнение, но не на запись.

[0018] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение изменения данных, используемых приложением типа С, приложением типа А/В, посредством перезаписи диска.

[0019] Резервация энергозависимого запоминающего устройства может быть ограничена заранее установленным максимальным количеством памяти на приложение. Каждое приложение типа А/В может резервировать энергозависимое запоминающее устройство только после того, как все приложения типа С зарезервируют энергозависимое запоминающее устройство.

[0020] Дополнительным отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение избыточного расходования энергозависимой памяти приложением типа А/В от сталкивания с приложением типа С отказом в энергозависимой памяти приложению типа С.

[0021] Резервация энергозависимого запоминающего устройства может ограничиваться заранее установленным общим максимальным количеством памяти для всех приложений.

[0022] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение неустойчивости системы, вызванной перераспределением энергозависимой памяти.

[0023] Операционная система может приводить в исполнение заранее установленный общий максимум и заранее установленный максимум на приложение, загружая регистры в диспетчер памяти, контролирующий доступ к энергозависимому запоминающему устройству.

[0024] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является применение диспетчера памяти, чтобы приводить в исполнение разделение памяти, что препятствует искажению, вызываемому работой приложения типа А/В. Настройки доступа к диспетчеру памяти могут быть ограничены операционной системой.

[0025] Операционная система может управлять планированием загрузки одного процессора для выполнения разных процессов прикладных программ и обеспечивать ограниченную максимальную процентную долю планирования для каждой прикладной программы.

[0026] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является применение алгоритма процесса планирования, который был бы устойчивым к полному захвату со стороны исполнимого приложения типа А/В.

[0027] Разные процессы приложений могут выстраиваться в очередь для одного процессора, так чтобы процессы для приложений типа С получали приоритет в очереди.

[0028] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является обеспечение работы приложений типа С в смешанной среде приложений.

[0029] Процессы могут помещаться ниже в очереди, когда они по протоколу используют всю свою запланированную процентную долю, по сравнению с тем, когда они по протоколу не используют всю свою запланированную процентную долю.

[0030] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение монополизации одного процессора определенным приложением.

[0031] Электронная система бортовой документации может также включать периферийные устройства, имеющие регистры конфигурации, и первая операционная система может блокировать доступ к этим регистрам приложениям типа А/В.

[0032] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение искажения работы периферийного устройства приложением типа А/В.

[0033] Электронная система бортовой документации дополнительно может включать систему отображения, обеспечивающую связь с одним процессором, чтобы обеспечить данные для дисплея, причем операционная система управляет отдельным буфером для каждого из, по меньшей мере, одного приложения типа С и одного приложения типа А/В и выбирает между буферами путем контроля операционной системы, так чтобы приложение типа А/В не могло писать данные поверх буфера для приложения типа С.

[0034] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение безвозвратного удаления приложениями типа А/В критических графических выходных данных из приложения типа С путем записи поверх этих выходных данных, как может произойти, если используется один буфер.

[0035] Отдельные буферы могут находиться в ячейках памяти, однозначно записываемых разными приложениями.

[0036] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является предотвращение выхода за границы буфера видеоинформации предотвращающего вывод графических данных приложениями типа С.

[0037] Операционная система может дополнительно выполняться на одном процессоре, чтобы обеспечивать данные для дисплея. Затем операционная система может управлять буфером видеоинформации приложения, получающим стандартные дисплейные данные от приложения, и оверлейным буфером видеоинформации, получающим от приложения типа С дисплейные данные с более высоким приоритетом, и может комбинировать содержимое буферов так, чтобы буфер приложения не мог загораживать данные из оверлейного буфера при выводе на дисплей.

[0038] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является обеспечение, чтобы критические графические данные не загораживались приложением типа А/В (или приложением типа С), некоторым образом сохраняя фокус.

[0039] Буферы могут быть разделены на функциональные зоны, и система отображения может по-разному перестраивать отношение между буферной ячейкой памяти и пространственными расположениями на дисплее для разных функциональных зон, в зависимости от указанной ориентации дисплея.

[0040] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является обеспечение сложного переформатирования дисплея в зависимости от ориентации дисплея без необходимости отдельно программировать два разных формата дисплея.

[0041] Система электронной памяти также может хранить вторую операционную систему, и приложение типа А/В может выполняться второй операционной системой путем виртуализации, осуществляемой первой операционной системой. Первой операционной системой, например, может быть сертифицированная операционная система с открытым кодом, тогда как второй операционной системой может быть частная операционная система, такая как Windows®.

[0042] Таким образом, отличительным признаком, по меньшей мере, одного варианта осуществления изобретения является разрешение использования приложений типа А/В, выполняемые только в частной операционной системе, которая не может быть проектно разрешена без подвержения риску возможность электронной системы бортовой документации быть использованной проектно разрешенными приложениями. Сегрегация и виртуализация операционной системы отделяет частную операционную систему, так чтобы ошибочное поведение не выходило за ее пределы.

[0043] Эти конкретные цели и преимущества могут применяться только к некоторым вариантам осуществления, попадающим под действие формулы, и потому не определяют объема изобретения.

Краткое описание графических материалов

[0044] Фиг.1 представляет собой блок-схему аппаратной части системы EFB предшествующего уровня техники, использующей отдельные процессоры, чтобы обособить приложения;

[0045] Фиг.2 представляет собой блок-схему аппаратной части подобную блок-схеме Фиг.1, показывающую систему EFB, использующую один процессор согласно данному изобретению;

[0046] Фиг.3 представляет собой функциональную блок-схему системы EFB по Фиг.2, показывающую обмен данными между системами памяти и одним процессором;

[0047] Фиг.4 представляет собой структурную схему, показывающую загрузку и запуск системы EFB по Фиг.2 и Фиг.3;

[0048] Фиг.5 представляет собой изображение конфигурационного файла и конфигурационной таблицы для прикладной программы, исполнимой в системе EFB по Фиг.2 и Фиг.3, используемых для загрузки и запуска;

[0049] Фиг.6 представляет собой подробное изображение памяти по Фиг.2, показывающее распределение различных структур данных и файлов;

[0050] Фиг.7 представляет собой изображение множественных буферов видеоинформации, которые, будучи скомбинированными графическим компоновщиком, используются разными исполняемыми приложениями, чтобы обеспечивать дисплей для электронной системы бортовой документации;

[0051] Фиг.8 представляет собой изображение шаблона приложения, поддерживающего две ориентации дисплея с одним двоичным приложением;

[0052] Фиг.9 представляет собой упрощенную схему системы планирования загрузки процессора, используемую в данном изобретении для выстраивания очереди прикладных процессов;

[0053] Фиг.10 представляет собой изображение энергонезависимого дискового накопителя, показывающее таблицу разделов для такового; и

[0054] Фиг.11 представляет собой схему виртуализации, которую можно осуществить с помощью данного изобретения.

Подробное описание предпочтительного варианта осуществления

[0055] Как показано на Фиг.1, система EFB 10 предшествующего уровня техники для использования на воздушном судне 12 может включать первый процессор 14 и второй процессор 16, обменивающиеся данными с первой и второй памятью 15 и 17, соответственно. Первый процессор 14 может использоваться, чтобы быть ведущим узлом для первого программного приложения 18, хранящейся в первой памяти 15, которой может быть, например, прикладная программа типа С. Второй процессор 16 может использоваться, чтобы быть ведущим узлом для второго программного приложения 20, хранящейся во второй памяти 17, которой может быть, например, программное приложение типа А/В. Блоки памяти 15 и 17 могут включать накопители на жестких магнитных дисках и флэш-память, чтобы обеспечивать несколько видов энергонезависимой памяти.

[0056] Процессоры 14 и 16 могут разделять общий модуль 22 отображения, имеющий одно жидкокристаллическое дисплейное (ЖКД) устройство 26. Каждый процессор 14 и 16 может обмениваться данными со своим собственным видеоконтроллером, 24 и 25. Первый процессор 14 может обмениваться данными с основным видеоконтроллером 24 и второй процессор 16 может обмениваться данными с вторичным видеоконтроллером 25. Два видеоконтроллера 24 и 25 могут обмениваться данными с ЖКД устройством 26 через систему Программируемых пользователем вентильных матриц (FPGA система), действующую в качестве системы 30 коммутации. Система 30 коммутации FPGA может быть под контролем одного процессора, например, первый процессор 14 может иметь основное устройство 35 шины, подключая его к системе 30 коммутации, так чтобы оно могло контролировать, который из процессоров, 14 или 16, передает данные на видеоинтерфейс 31. Подобное условие может проявиться, когда возникает необходимость отобразить более важную информацию о полете или воздушном судне, в то время как модуль отображения 22 используется, чтобы отображать менее важную информацию, подаваемую вторым программным обеспечением 20, выполняемой на втором процессоре 16. Система 30 коммутации может обмениваться данными с ЖКД 26 посредством интерфейса 31 дисплея, подавая сигналы на схему 27 драйвера ЖКД дисплея 26 и получая сигналы от клавиш или сенсорного ЖКД экрана 42. Внешняя клавиатура 36 может быть подключена к интерфейсу 31 дисплея. Процессоры 14 и 16 могут также обмениваться данными со стандартной сетью типа Ethernet (не показано) для обмена данными с другими устройствами, такими как аэрокамеры и подобными как это понимается в области техники.

[0057] Каждый процессор 14 и 16 также может обмениваться данными со своим собственным входным интерфейсом 29, получающим сигналы от клавиш и сенсорного ЖКД экрана 42 или внешней клавиатуры 36.

[0058] Как показано на Фиг.1, может возникнуть необходимость ограничить доступ и видимость интерфейсов 43 авиационного оборудования для другого авиационного оборудования воздушного судна 12 из соображений безопасности. Плата 34 ввода-вывода обеспечивает доступ к интерфейсу 43 авиационного оборудования, так чтобы система EFB 10 могла взаимодействовать с другим оборудованием, установленным на воздушном судне 12. Плата 34 ввода-вывода может состоять из микроконтроллера, содержащего встроенное программное обеспечение, поддерживающее схему, и схемы, спроектированной, чтобы подключаться к интерфейсу 43 авиационного оборудования известного в области техники типа. Разрешение первому процессору 14 задавать начальные значения и конфигурацию карты 34 ввода-вывода позволит первому процессору 14 ограничивать доступ второго процессора 16 к интерфейсам 43 авиационного оборудования. Эта способность позволяет системе EFB 10 отвечать необходимым стандартам безопасности.

[0059] При определенных обстоятельствах может возникнуть необходимость первого процессора 14 отключить или перезапустить второй процессор 16; либо из-за неисправности второго процессора 16, либо из-за программной ошибки программного обеспечения 20. Первый процессор 14 может посылать второму процессору 16 сигнал 33 сброса, который позволяет первому процессору 14 отключать или перезапускать второй процессор 16. Это обеспечивает первому процессору 14 полный контроль над модулем 22 отображения (через систему 30 коммутации), а также над вторым процессором 16. Это устраняет необходимость в дорогостоящей сертификации второго приложения в соответствии с высокими стандартами FAA, регулирующими использование прикладных программ в системах EFB 3-го класса на коммерческих воздушных суднах 12. Таким образом, второе программное приложение 20 может представлять собой коммерческое, готовое программное приложение. Даже если второе программное приложение 20 обеспечивается в качестве заказного программного приложения, это все равно дает значительное преимущество, поскольку устраняется дорогостоящая и трудная сертификация, необходимая для приложений типа С. Это возможно благодаря тому, что первому процессору 14 обеспечивается способность полностью лишать контроля модуль 22 отображения и второй процессор 16, что может понадобиться, когда на дисплей необходимо вывести важную информацию, или когда требуется немедленный ответ оператора.

[0060] Как показано на Фиг.2, данное изобретение обеспечивает систему EFB 10', в которой сложную двухпроцессорную систему и аппаратные коммутаторы, используемые, чтобы обеспечивать преобладание одного процессора над другим, можно выгодно заменить одним процессором 50. Этот один процессор 50 выполняет множественные прикладные программы 52 (приложения типа А, В или С), хранящиеся в памяти 15, используя модифицированную особым образом операционную систему 54, как будет описано ниже. Модифицированная особым образом операционная система 54 контролирует выполнение всего остального программного обеспечения, ведущим узлом которого является система EFB 10'. Главная программа 53 меню, связанная с внутренними операциями системы EFB 10, также может храниться в памяти 15 и выполняться процессором 50. Для ясности описания, под «операционной системой» как здесь будет пониматься ядро операционной системы в сочетании с дополнительными корневыми службами, драйверами и другим программным обеспечением, используемым, как правило, множественными приложениями, и необходимым для выполнения прикладных программ.

[0061] В этой архитектуре процессор 50 может обмениваться данными с интерфейсом 34, не нуждаясь в системе коммутации, и интерфейс 34 может подключаться через устройство 35 шины к различным устройствам ввода 36 и 42, подобным описанным ранее. Интерфейс 34 также может подключаться к системам авиационного оборудования, включая навигационное устройство, через интерфейсы 43 авиационного оборудования. Процессор 50 также может обмениваться данными с видеоконтроллером 24, имеющим всего один графический процессор и данные для выведения на дисплей 22 посредством интерфейса 34. Процессор 50 также может обмениваться данными с входным интерфейсом 29, получающим сигналы от клавиш и сенсорного экрана 42 и внешней клавиатуры 36, опять же посредством интерфейса 34.

[0062] Как показано на Фиг.3, процессором 50 может быть, например, процессор, имеющий множество ядер 56, у каждого из которых, например, есть кэш L1 58 и общий кэш L2 60. Кэш L2 60 может подключаться через одну или более внутренних шин к оперативной энергозависимой памяти 64 и энергонезависимой памяти 66, причем последняя, например, логически является «дисковым» накопителем, реализованным, например, флэш-памятью, и обе являются частью системы 62 памяти. Доступ к энергозависимой памяти 64 может осуществляться через диспетчер 68 памяти, а доступ к энергонезависимой памяти 66 может осуществляться через дисковый контроллер 70 хорошо известных в области техники типов.

[0063] Как показано на Фиг.4, процессор 50 может выполнять процедуру 76 загрузки перед и в различные моменты во время использования системы EFB 10' на воздушном судне, процедура 76 загрузки используется, чтобы устанавливать и задавать конфигурацию желаемых прикладных программ. На первом шаге, указанном в оперативном блоке 80, процедура 76 загрузки запускает программу-загрузчик. Посредством оперативного блока 82, программа-загрузчик проводит анализ идентифицированных прикладных программ 52, подлежащих использованию в электронной системе бортовой документации 10', вместе с конфигурационным файлом 84 (в качестве части файла описания), связанным с прикладными программами 52, и идентифицирует прикладные программы 52 как приложения таким образом, что это влияет на их размещение в разделах диска.

[0064] Как показано одновременно на фигурах 3 и 5, в конфигурационном файле 84 могут быть записи 86 для каждой прикладной программы 52, связанной с исполняемым модулем 88 для этого приложения. Запись 86 для каждого конфигурационного файла 84, в общем случае, обеспечит идентификатор 90 приложения, идентифицирующий исполнимый модуль 88 и его процессы (например, с идентификатором групп), и приложение типа 92 (например, типа А, типа В или типа С) и укажет объем памяти, подлежащий резервированию для приложений 96. Информация из конфигурационного файла 84 будет добавлена в конфигурационную таблицу 94, построенную для этой прикладной программы 52 во время запуска операционной системы 54. Конфигурационная таблица 94 добавит дополнительную информацию, которая будет описана ниже, в том числе информацию 98 распределения памяти диспетчера памяти, определяющую группу полномочий, информацию 102 буфера видеоинформации, связанную с каждой прикладной программой 52, как будет описано ниже.

[0065] Как показано на фигурах 4 и 10, используя информацию, полученную из оперативного блока 82, в оперативном блоке 106, прикладные программы 52 устанавливаются в энергонезависимой памяти 66, в предварительно подготовленные разделы 99. Процесс разбивки на разделы выделяет отдельный раздел диска 99a-d, включающий первый раздел диска 99а, хранящий исполнимые модули для прикладных программ (а также для операционной системы, что предусматривает только доступ чтения и выполнения файлов, содержащихся в этом разделе, но не доступ записи). Второй раздел 99b предусматривает доступ чтения/записи, но не выполнения и используется прикладными программами для временных файлов и записей. Третий раздел 99 с предусматривает только доступ чтения, не предусматривает выполнения файлов, содержащихся в этом разделе, и может использоваться для баз данных, совместно используемых приложениями. Четвертый раздел 99d хранит программы, которые являются доступными, но еще не установленными; он не является исполнимым, и читается и записывается, но только операционной системой. Благодаря тому, что приложения помещаются в первый раздел 99 диска, случайные приложения не могут переписывать дисковые файлы других приложений. "Каждый раздел 99 описан в таблице 110 разделов как указанный, в общем случае, рядом в таблице 110 разделов. Специалисту в области техники понятно, что раздел 99 будет включать собственную файловую систему 112 (устанавливающую соответствие между логическими адресами и физическими адресами на диске) и собственную область памяти 114, устанавливающую соответствие с предопределенным и ограниченным диапазоном 116 физического адреса в том виде, в каком он осуществляется операционной системой, и кодировкой информации на дисковом носителе. Таблица 110 разделов может обеспечивать логический идентификатор для каждого из разделов (обозначенных здесь а, b, с, d.), информацию 120 физического адреса для файловой системы 112 и полномочия 122 доступа к данным, указывающие прикладную программу 52, имеющую полномочие читать или писать в данном конкретном разделе. Другие методы разбивки на разделы для осуществления полномочий доступа также рассматриваются в изобретении.

[0066] В общем случае, каждая прикладная программа 52 будет загружаться в собственную уникальную папку в разделе 99а и обеспечивается «корневой тюрьмой», которая не дает ей видеть части файловой системы 112, связанные с другими директориями. «Петлевые устройства» известного в области техники типа используются, чтобы предоставить заданным прикладным программам доступ только к соответствующим частям разделов 99b и 99с. Путем ограничения доступа к регистрам конфигурации аппаратной части дискового контроллера и/или ограничения обращений операционной системы, доступных прикладным программам, аппаратная часть дискового контроллера может обеспечивать устойчивую к сбоям реализацию разделов, предотвращающую возможное поведение случайного приложения, при котором одно приложение пишет поверх второго приложения или его данных.

[0067] Как показано на Фиг.4, после, по меньшей мере, одного завершения процедуры 76 загрузки, процессор 50 может выполнять процедуру 126 запуска, начинающуюся с оперативного блока 132. Эта процедура 126 запуска является осуществляемой операционной системой 54 и переносит различные прикладные программы 52 в энергозависимую память 64 для выполнения. Этот процесс запуска опять же контролируется конфигурационной таблицей 94 и, в частности, идентификацией каждой прикладной программы как принадлежащей к типу А, В или С. В предпочтительном варианте осуществления процесс запуска начинается с приложений типа С, а приложения типа А и типа В запускаются только после того, как запустятся все приложения типа С согласно петле, границы которой заданы оперативными блоками 134 и 136.

[0068] Как также показано на Фиг.6, на первых шагах этого процесса запуска для хранения исполнимых файлов операционной системы 54 и различных прикладных программ 52 резервируется операционной системой 54 энергозависимая память 64. Это резервирование может приводиться в исполнение диспетчером 68 памяти (показано на Фиг.1) путем загрузки управляющих регистров диспетчера памяти 68 с данными, чтобы контролировать установление соответствия между логическими адресами и физическими адресами энергозависимой памяти 64, и вместе с операционной системой, чтобы контролировать доступ к каждому адресному диапазону оперативной памяти 64, используемой каждой прикладной программой 52 (согласно группам, присвоенным процессам каждой прикладной программы). Адресация логической памяти управляющих регистров может быть представлена в виде пространства 65 регистровой памяти, и, таким образом, сам диспетчер 68 памяти может ограничивать доступ диспетчера 68 памяти к управляющим регистрам операционной системой 54.

[0069] Перед первыми шагами процедуры 126 запуска первым адресным диапазоном 138 будет назначена операционная система 54, чтобы хранить исполнимый модуль операционной системы, данные ее памяти 140, и память, зарезервированную для буферов 142 сокета. Полномочие на запись этого первого адресного диапазона 138 данных обеспечивается только операционной системе 54 согласно настройкам операционной системы.

[0070] Как отмечалось ранее, адресные диапазоны каждой из прикладных программ 52 также резервируются в оперативном блоке 148. Данное изобретение резервирует только предопределенный, фиксированный адресный диапазон 152 для каждой прикладной программы 52, определяемый по конфигурационному файлу, и этот процесс резервации начинается с идентификации по конфигурационной таблице 94 приложений типа С. Каждый зарезервированный адресный диапазон 152 должен хранить объектный файл 154 самой прикладной программы 52 (хранящий команды на выполнение), и пространство данных внутри зарезервированного адресного диапазона 152 распределяется так, как необходимо приложению, что будет описано ниже. Полномочия для зарезервированного адресного диапазона 152 приложения установлены, как отмечалось выше, так чтобы прикладные программы 52 не могли записывать за пределами уникальных адресных диапазонов 152, хранящих их исполнимые модули 88, что предотвращает вмешательство приложений друг в друга и, например, запись прикладных данных приложения типа А/В поверх приложения типа С, приводящую к негативным последствиям. Если возникает недостаток памяти, чтобы гарантировать, что всем приложениям типа С может быть предоставлено их максимальное зарезервированное количество памяти согласно конфигурационному файлу 84, то прикладная программа 52 типа А/В, которая в последствии запросит зарезервировать больше памяти, не запустится, и будет сделано сообщение и запись об ошибке.

[0071] Для того чтобы обеспечить, что приложения типа А/В не смогут позднее занять память, необходимую для надежного функционирования приложений типа С, все лимиты для приложений типа С получат оценку, и приложения типа С будут запущены первыми. Оставшаяся память будет доступной для приложений типа А/В. Если заданный конфигурацией лимит для приложения типа А/В превышает то, что остается доступным, после того как все приложения типа С получают оценку, приложение не будет запущено. Эта оценка выполняется с использованием максимальных лимитов, указанных в проектно разрешенном конфигурационном файле, а не текущим объемом памяти, который используют приложения типа С.

[0072] Как это понимается в области техники, буферы 142 сокета могут использоваться, чтобы обеспечивать подобный сетевому обмен данными в реальных сетях (например, в сети 45) или между прикладными процессами, где буферы 142 сокета обеспечивают хранение данных, пересылаемых между пунктами сети, или приложений, которые должны быть доступны для разных программ или устройств. Поскольку буфер 142 сокета хранится в первом адресном диапазоне 138 операционной системы 54, неправильное использование памяти сокета (например, если открыто слишком много сокетов или сокеты слишком большие) может помешать работе системы.

[0073] Как показано на Фиг.4, в оперативном блоке 156 буферы 142 сокета, необходимые каждой прикладной программе 52, зарезервированы в пределах первого адресного диапазона 138. Чтобы предотвратить возможное перераспределение адресного диапазона 138 буферами сокета 142, которое может повлиять на работу операционной системы 54 или ее прикладных программ 52, данное изобретение ограничивает как общее число буферов сокета 142, так и их максимальный размер предопределенными значениями, полученными из конфигурационных данных 84. Таким образом, может быть гарантировано, что буферы сокета 142 не выйдут за пределы доступного пространства памяти путем обеспечения адресного диапазона 138, который может хранить это предопределенное общее число сокетов предопределенного максимального размера. На практике структура, связанная с каждым приложением 52, хранящимся в памяти операционной системы, проверяется, когда прикладной процесс запрашивает сокет-соединение. Если этот запрос переполнит сокет-память, запрос будет отклонен операционной системой 54.

[0074] В оперативном блоке 160 каждый из вышеописанных буферов 158 видеоинформации зарезервирован в диапазоне памяти, присвоенном операционной системе 138 для приложений, которым требуется доступ к системе отображения 26.

[0075] Как только каждая прикладная программа 52 запущена, и необходимая энергозависимая память 64 зарезервирована, операционная система 54 может планировать согласно оперативному блоку 162 процессы для каждой из прикладных программ 52, такие процессы, которые могут планироваться планировщиком операционной системы, как сейчас будет описано.

[0076] Как показано на Фиг.9, планировщик 161 операционной системы может обеспечивать очередь 164 планируемых задач, хранящую идентификаторы 166 процесса для процессов, порождаемых прикладными программами 52. Эти процессы будут выполняться процессором 50 согласно системе временных интервалов, при которой, например, у каждого процесса есть предопределенное максимальное количество процессорного времени до того как начинает выполняться следующий процесс. Не до конца выполненные процессы возвращаются в таблицу 168 процессов, хранящую все незаконченные процессы. Таблица 168 процессов также хранит процессы, которые порождаются другими процессами.

[0077] В логическом представлении таблица 168 процессов обеспечивает последовательность рядов, каждый из которых представляет процесс, подлежащий планированию планировочным механизмом 170 для помещения в очередь 164 для выполнения процессором 50 в порядке очереди. Каждый ряд включает идентификационный номер 166 процесса, тип 172 базового приложения (например, тип С), и свежий протокол выполнения процесса 174. Планировочный механизм 170 работает, чтобы планировать всякое приложение типа С в таблице 168 перед приложениями типа А/В, и далее работает, чтобы назначать более высокий приоритет процессам, которые не использовали весь свой временной интервал при предыдущей возможности планировки, согласно протоколу процесса 174.

[0078] Таким образом, планировочный механизм 170 использует штрафную систему, чтобы «наказывать» приложения 52, которые ранее захватывали неадекватно большую долю ресурсов ЦП, что опускает их еще ниже в очереди задач, заставляя дольше ждать доступа к ЦП. Штрафуя приложения, которые всегда используют максимальное количество выделенного времени ЦП, ядро заставляет их опуститься в конец очереди задач, обеспечивая таким образом, чтобы каждый процесс имел доступ к ЦП, и надлежащий приоритет приложения можно контролировать, адекватно устанавливая максимально допустимое время ЦП в конфигурационном файле.

[0079] Как показано на фигурах 6 и 7, каждую прикладную программу 52, представленную объектным файлом 154, операционная система 54 обеспечивает отдельным локальным графическим буфером 158. Этот графический буфер 158 включает память, используемую, чтобы хранить информацию о состоянии и общие глобальные конструкции (текстуры, шрифты, и т.д.), и кадровый буфер, который может хранить изображение для вывода на экран 26 дисплея, достаточным, чтобы полностью описать видимое изображение в области экрана 26 дисплея. Один или более стандартных модулей 180 графического процессора могут обрабатывать графические представления к операционной системе 54, чтобы производить отдельные полностью визуализированные карты экрана в частях кадрового буфера графического буфера 158, обеспечивая значения пикселов, устанавливающие с экраном 26 дисплея соответствие на взаимно-однозначной основе. Эти карты экрана могут затем комбинироваться графическим процессором 180 в буфер экрана путем процесса комбинирования, который выбирает из данных графических буферов 158 (согласно фокус-информации, которую обеспечивает операционная система 54), чтобы отобразить данные одного из графических буферов 158 на экране 26 дисплея. Этот процесс сохраняет базовые графические данные каждого приложения 154, так чтобы они не терялись со сменой фокуса и, что важно, так чтобы случайное приложение типа А/В не могло уничтожить данные приложения типа С таким образом, чтобы операционная система 54 не могла их восстановить.

[0080] Операционная система 54 создает оверлейный графический буфер 158', который во время процесса комбинирования всегда помещается «впереди» графической информации из графических буферов 158. Эти данные в оверлейном графическом буфере 158' всегда находятся поверх всех и/или могут пользоваться параметрами прозрачности. Этот оверлей может использоваться, чтобы сообщать высокоприоритетную системную информацию (предупреждения, уведомления, и т.д..), такую, которую могут генерировать приложения типа С, а также чтобы обеспечивать глобальные системные интерфейсы, такие как клавиатуры сенсорного экрана, цифровые клавиатуры или навигационные клавиши.

[0081] Как показано на Фиг.8, каждый графический буфер 158 можно разделить на разные функциональные зоны 190 (здесь изображены как хранящие образы, но могут также хранить графические команды более высокого уровня). Функциональные зоны 190 таковы, чтобы отделять данные, которые можно независимо разместить на экране 26 дисплея. Графический компоновщик 186 может принимать команду 196 положения экрана, указывающую ориентацию экрана дисплея либо в портретном режиме, изображенном на экране 26а дисплея, либо в ландшафтном режиме, изображенном на экране 26b дисплея, причем при последнем длинная сторона располагается горизонтально, а при первом длинная сторона располагается вертикально. Исходя из этой команды 196 положения экрана, полученной, например, из настроек в конфигурационной таблице 94, графический компоновщик 186 будет менять пространственное расположение функциональных зон 190, чтобы обеспечить лучшее размещение дисплея. Так, например, функциональные зоны 190 могут включать функциональные зоны 190а, описывающие клавиши сенсорного экрана, и функциональные зоны 190b, описывающие выходной графический образ. Для ландшафтного экрана 26b дисплея образы клавиш, получаемые из функциональных зон 190а, могут помещаться сбоку выходного графического образа, получаемого из функциональной зоны 190b, тогда как при портретном экране 26а дисплея образы клавиш, получаемые из функциональных зон 190а, могут помещаться под выходным графическим образом, получаемым из функциональной зоны 190b. Таким образом, нет необходимости жестко программировать отдельные виды экрана в графическом буфере 158.

[0082] Альтернативно, понятно, что функционально идентичный результат можно обеспечить, применяя графическую библиотеку, которая использует знание об ориентации экрана, чтобы автоматически регулировать положение графических элементов, запрашиваемых приложением.

[0083] Как показано Фиг.11, возможность использовать один процессор 50, чтобы выполнять множественные прикладные программы 52, имеющие разные уровни сертификации, можно расширить, чтобы позволить одному процессору 50 и операционной системе 54 выполнять вторую операционную систему 212 посредством виртуализации. Эта виртуализация позволяет некоторым из прикладных программ 52 выполняться в разных операционных системах 212, которые проектно разрешены операционной системой 54. Так, например, вышеописанные модификации могут быть применимы к проектно разрешенным приложениям, работающим на базе Linux, и в то же время могут использоваться некоторые приложения типа А/В, предназначенные для операционной системы 212Windows®, благодаря тому, что операционная система 54 Linux может выполнять операционную систему 212 Windows® как рабочее приложение.

[0084] В этом варианте осуществления проектно разрешенное ядро 200 на базе Linux операционной системы 54 может включать в себя виртуализатор, такой как гипервизор 210, позволяющий выполнять гостевую операционную систему 212, как правило, коммерческую операционную систему, такую как операционная система Windows®. Гипервизор 210 представляет собой виртуальную аппаратную платформу для гостевой операционной системы 212, позволяющую последней выполнять прикладные программы 52 типа А и типа В, предназначенные для операционной системы Windows®. Ядро Linux 200 может напрямую выполнять прикладные программы 52 типа С.

[0085] Как это понимается в области техники, гипервизор 210 обеспечивает интерфейс для реального аппаратного обеспечения посредством драйверов 214 виртуальных устройств, установленных на коммерческой операционной системе, и слоя 216 виртуализации, создающего видимость, что коммерческая операционная система 212 является реальной физической машиной, то есть, видимость процессора, памяти и аппаратного обеспечения. В то же время работа виртуальной машины контролируется гипервизором 210 и операционной системой 54 в том виде, который описан выше, чтобы ограничить использование реальных физических ресурсов процессора 50 и системной памяти 62 коммерческой операционной системой 212 и ее прикладными программами 52, и чтобы она подчинялась проектно разрешенной операционной системе 54. С виртуальной машиной обращаются так, как если бы она (совокупность коммерческой операционной системы, драйверов и приложений, для которых они являются ведущими узлами) была самостоятельным приложением типа А/В. Операционной системе 212 Windows® может быть выделен собственный раздел, как любой другой прикладной программе 52, в энергонезависимой памяти 66 и энергозависимой памяти 64, и операционная система 212 Windows® может подвергаться другим ограничениям, описанным выше в связи с обычными приложениями.

[0086] При этих условиях прикладная программа 52 типа С может выполняться напрямую проектно разрешенной операционной системой 54 и, таким образом, может получить приоритет по ресурсам, включая процессорное время и пространство дисплея.

[0087] Виртуализация может обеспечивать снижение быстродействия, особенно по отношению к графическим операциям, которые могут осуществляться, по меньшей мере частично, в программном обеспечении или в значительной степени транслироваться в виртуализованную среду. По этой причине в данном изобретении рассматривается туннелирование 220 между драйверами виртуальных устройств и аппаратными драйверами 232 операционной системы 54. Это туннелирование 220 может осуществляться посредством модификации коммерческой операционной системы 212, чтобы обойтись без драйверов 214 виртуальных устройств и слоя виртуализации 216 и передавать команды через ядро 200 напрямую к реальным аппаратным драйверам 232. Таким образом, устраняется задержка в работе из-за слоя 216 виртуализации и гипервизора 210, равно как и задержка, которая может произойти, когда графические команды реализуются в программном обеспечении посредством виртуализации, а не напрямую аппаратной частью видеоконтроллера 24.

[0088] Риск, что это туннелирование нарушит приоритет приложений типа С над приложениями типа А/В, находится под контролем благодаря тому, что операционная система 54 может включать и отключать туннелирование 220, например, направляя драйверы 232 между разными командными буферами, причем один используется драйверами 214 виртуальных устройств и туннелированием 220, а другой используется прикладными программами 52, ведущим узлом которых является проектно разрешенная операционная система 54.

[0089] Дополнительное увеличение быстродействия может быть получено, используя значительно упрощенную коммерческую операционную систему, удалив поддержку, например, для аппаратных компонентов, которые не реализуются в электронной системе бортовой документации 10'.

[0090] Дополнительное увеличение быстродействия может быть получено, выполняя разные наборы прикладных программ 52 посредством разных множественных коммерческих операционных систем 212 (не показано). Использование разных виртуальных машин позволяет каждой виртуальной машине «подстраиваться» к типу прикладных программ 52, которые они будут выполнять, путем изменения ресурсов, выделяемых каждой виртуальной машине, представленной отдельной операционной системой 212. Например, прикладные программы 52, интенсивно использующие память, могут выполняться на виртуальной машине, которой выделено соразмерно больше памяти; приложения, требующие большого объема вычислений, могут выполняться на виртуальной машине 64а, которой выделен значительный ресурс процессора. Подобным образом могут регулироваться аппаратные ресурсы, такие как сетевой доступ и так далее. Таким образом, ресурсы могут лучше распределяться, уменьшая потери быстродействия из-за виртуализации. Например, дополнительная память может несоразмерно повысить скорость процесса, при условии, что память для данных виртуальных машин может позитивно влиять на производительность даже после простого раздела памяти между виртуальными машинами. Такая подгонка возможна благодаря закрытым аппаратным средам электронной системы бортовой документации 10'.

(0091] Следует отдельно отметить, что данное изобретение не должно ограничиваться вариантами осуществления и примерами, содержащимися в данной заявке, и пункты формулы необходимо понимать как включающие модифицированные формы тех вариантов осуществления, в том числе частей вариантов осуществления и комбинаций элементов разных вариантов осуществления, которые находятся в пределах объема следующих пунктов формулы. Все описанные здесь публикации, включая патенты и не патентные публикации, включаются в данную заявку во всей полноте посредством ссылки.

Изобретение относится к вычислительной технике. Технический результат заключается в получении однопроцессорной архитектуры с обособленностью, эквивалентной мультипроцессорной системе. Электронная система бортовой документации 3-го класса содержит один процессор, имеющий по меньшей мере одно ядро; систему электронной памяти, обменивающуюся данными с процессором и хранящую операционную систему; сетевой интерфейс, обменивающийся данными с бортовой сетью передачи данных, чтобы подключаться к другому бортовому оборудованию, в том числе навигационным системам; дисплей, обменивающийся данными с процессором; где операционная система выполняет ограничение доступа приложений типа А/В в системе электронной памяти к электронной памяти, дисплею и процессору; где приложению типа С проектно разрешено взаимодействовать с бортовой сетью передачи данных, а приложению типа А/В проектно не разрешено взаимодействовать с бортовой сетью передачи данных, где операционная система управляет отдельным буфером для каждого из по меньшей мере одного приложения типа С и одного приложения типа А/В и выбирает из буферов путем контроля операционной системы так, чтобы приложение типа А/В не могло перезаписывать данные буфера для приложения типа С. 20 з.п. ф-лы, 11 ил.

1. Электронная система бортовой документации 3-го класса, содержащая:
один процессор, имеющий по меньшей мере одно ядро;
систему электронной памяти, обменивающуюся данными с процессором и хранящую операционную систему;
сетевой интерфейс, обменивающийся данными с бортовой сетью передачи данных, чтобы подключаться к другому бортовому оборудованию, в том числе навигационным системам;
дисплей, обменивающийся данными с процессором;
где операционная система выполняет ограничение доступа приложений типа А/В в системе электронной памяти к электронной памяти, дисплею и процессору, согласно заданным правилам, приводимым в исполнение операционной системой, чтобы блокировать потенциальное вмешательство выполнения приложения типа А/В в выполнение приложения типа С;
где приложению типа С проектно разрешено взаимодействовать с бортовой сетью передачи данных, а приложению типа А/В проектно не разрешено взаимодействовать с бортовой сетью передачи данных,
где операционная система выполняется на одном процессоре, чтобы обеспечить данные для дисплея, причем операционная система управляет отдельным буфером для каждого из по меньшей мере одного приложения типа С и одного приложения типа А/В и выбирает из буферов путем контроля операционной системы так, чтобы приложение типа А/В не могло перезаписывать данные буфера для приложения типа С.

2. Электронная система бортовой документации 3-го класса по п. 1, где операционная система ограничивает общий размер буферов сокетов, используемых для обмена данными.

3. Электронная система бортовой документации 3-го класса по п. 2, где общий размер буферов сокетов ограничен заданным максимальным размещением данных на сокет и заданным максимальным количеством сокетов.

4. Электронная система бортовой документации 3-го класса по п. 1, где сетевые широковещательные сообщения запрещены.

5. Электронная система бортовой документации 3-го класса по п. 1, где система электронной памяти включает энергонезависимое запоминающее устройство и где каждое приложение присвоено разделу, имеющему разрешение на чтение и выполнение, но не на запись.

6. Электронная система бортовой документации 3-го класса по п. 1, где система электронной памяти включает энергозависимое запоминающее устройство и где каждому приложению типа А/В энергозависимое запоминающее устройство резервируется только после того, как энергозависимое запоминающее устройство резервируется всем приложениям типа С.

7. Электронная система бортовой документации 3-го класса по п. 6, где резервация энергозависимого запоминающего устройства ограничена заданным максимальным количеством памяти на приложение.

8. Электронная система бортовой документации 3-го класса по п. 7, где резервация энергозависимого запоминающего устройства ограничена заданным общим максимальным количеством памяти для всех приложений.

9. Электронная система бортовой документации 3-го класса по п. 7, где операционная система приводит в исполнение заданный общий максимум и заданный максимум на приложение, загружая регистры в диспетчер памяти, контролирующий доступ к энергозависимому запоминающему устройству.

10. Электронная система бортовой документации 3-го класса по п. 1, где операционная система управляет планированием загрузки одного процессора для выполнения разных процессов приложений и обеспечивает ограниченную максимальную процентную долю планирования для каждого приложения.

11. Электронная система бортовой документации 3-го класса по п. 10, где разные процессы приложений выстраиваются в очередь для одного процессора, так чтобы процессам для приложений типа С давался приоритет в очереди.

12. Электронная система бортовой документации 3-го класса по п. 11, где процессы размещены ниже в очереди, когда они по протоколу используют всю свою процентную долю планирования, по сравнению с тем, когда они по протоколу не используют всю свою процентную долю планирования.

13. Электронная система бортовой документации 3-го класса по п. 1, где электронная система бортовой документации дополнительно включает периферийные устройства, имеющие регистры конфигурации, и где операционная система блокирует доступ к этим регистрам приложениям типа А/В.

14. Электронная система бортовой документации 3-го класса по п. 1, где отдельные буферы находятся в ячейках памяти, однозначно записываемых разными приложениями.

15. Электронная система бортовой документации 3-го класса по п. 1, где операционная система выполняется на одном процессоре, чтобы обеспечить данные для дисплея, причем операционная система управляет буфером приложения, получающим от приложения стандартные данные дисплея, и оверлейным буфером, получающим от приложения типа С данные дисплея с более высоким приоритетом, операционная система комбинирует содержимое буферов, так чтобы буфер приложения не мог загораживать данные из оверлейного буфера при выводе на дисплей.

16. Электронная система бортовой документации 3-го класса по п. 1, где буферы разделены на функциональные зоны и где для разных функциональных зон система отображения по-разному перестраивает отношение между буферной ячейкой памяти и пространственными положениями на дисплее, в зависимости от указанной ориентации дисплея.

17. Электронная система бортовой документации 3-го класса по п. 1, где система электронной памяти также хранит вторую операционную систему и где приложение типа А/В выполняется второй операционной системой путем виртуализации, осуществляемой операционной системой.

18. Электронная система бортовой документации 3-го класса по п. 17, где операционная система выполняет вторую операционную систему, как если бы вторая операционная система была приложением типа А/В.

19. Электронная система бортовой документации 3-го класса по п. 17, где операционная система ограничивает доступ второй операционной системы к электронной памяти, дисплею и процессору, согласно заданным правилам, приводимым в исполнение операционной системой, чтобы блокировать потенциальное вмешательство выполнения второй операционной системы в выполнение приложений типа С.

20. Электронная система бортовой документации 3-го класса по п. 17, где операционная система является проектно разрешенной операционной системой, а вторая операционная система является проектно не разрешенной операционной системой.

21. Электронная система бортовой документации 3-го класса по п. 19, где второй операционной системой является Windows®.