source

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

Технические специалисты были бы рады изобретению такого философского камня, который, если даже не обеспечил бы безопасность, то, по крайней мере, оценил бы ее с требуемым уровнем полноты. Подобные наработки существуют уже более 20 лет, однако, практически не известны русскоязычному читателю. Речь пойдет о методологии Assurance Case (или Safety Case), под которой подразумевается структурированный набор аргументов и документальных подтверждений, обосновывающих соответствие системы или сервиса заданным требованиям.

Введение

Перед прочтением статьи хотел бы обратить ваше внимание на пару важных моментов. Изложенный материал применим, в первую очередь, для объектов критической информационной инфраструктуры (КИИ). Для таких объектов, в частности, для информационных и управляющих систем, должен быть выполнен анализ безопасности. Результаты анализа безопасности представляются в виде соответствующих отчетов. Все это выполняется уже десятки лет, однако, отчеты, как правило, имеют произвольную текстовую форму, в логике которой не всегда просто разобраться.

Основная идея излагаемого подхода состоит в том, что результаты анализа безопасности могут быть представлены в графическом виде с использованием полуформальных нотаций, со всеми вытекающими отсюда преимуществами. Таким образом, Assurance Case является способом интегрального представления всех мер по обеспечению и оцениванию безопасности, не заменяя и не отменяя такие частные методы, как, например, тестирование, статический анализ кода, расчет надежности, FMEA, анализ рисков и т.п. Данная статья продолжает ранее опубликованную серию статей по безопасности.

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

Как мы можем понять или утверждать, что некоторый объект является безопасным? Очевидно, для этого надо ввести ряд критериев. Однако, для этих критериев нам необходимо определить, насколько наше знание об объекте является достоверным? Почему мы можем этому знанию доверять? Что делает наши доводы и рассуждения действительно заслуживающими доверия? Углубившись в подобные проблемы, нельзя обойтись без философских дисциплин, таких как, онтология, гносеология, эпистемология, логика, а также, без великих мыслителей, которых волновали эти вопросы. В античном мире таковыми являлись Аристотель и Платон, а в эпоху нового времени основоположником современного научного метода считается Френсис Бэкон.

Что же можно сделать для обоснования или оценки безопасности разумным и логичным путем? В основе такого подхода лежит теория аргументации. Новый импульс современному развитию аргументации был дан в работе британского философа Стивена Тулмина под названием The Uses of Argument, изданной в 1958 году. Тулмин расширил логический импликативный вывод дополнительными параметрами и предложил представлять эту операцию в графической форме. Нотация Тулмина оперирует следующими сущностями: data (D) исходные данные для анализа, claim (С) цель логического импликационного вывода (If D So C), warrant (W) дополнительный аргумент, qualifier (Q) степень уверенности в результатах логического вывода, rebuttable (R ) дополнительный контраргумент (Рисунок 1).


Рисунок 1. Нотация Стивена Тулмина

Карты аргументов или аргументации (Argument Map) использовались в целях визуализации рассуждений и до Тулмина, но именно он наиболее удачно обобщил структурную модель для анализа и верификации аргументов. Отметим, что в современных картах аргументов, как правило, не используется нотация Тулмина, все упрощено, например, как на рисунке ниже. Это нотация, используемая платным онлайн сервисом Rational (бесплатная версия существует, но она крайне ограничена по функционалу) (Рисунок 2). Платная версия умеет преобразовывать полученные диаграммы в логически структурированный текст. На сайте также доступны бесплатные guides & tutorials по критическому мышлению и составлению карт аргументов.


Рисунок 2. Карта аргументов, разработанная при помощи сервиса Rational

Как видим, все довольно прозрачно, существуют всего четыре сущности и три типа связи между ними. Результат логического ввода называется Contention, подтверждающий аргумент Reason (связь because), контраргумент Objection (связь but), а вот контраргумент для контраргумента имеет специальное название Rebuttal (связь however).

На данный момент не существует общепринятой нотации для составления карт аргументов. Нет единства и в обозначениях, применяемых для структуры аргументов. Например, результат логического вывода может называться claim, contention, conclusion, goal. Аргументы могут называться premise, justification и т.д. В области моделирования аргументов существует ряд международных инициатив и сообществ (например, Argument Interchange Format, AIF), но вопросы унификации они не решили. Существуют исследования, проводящие параллели между картами аргументов и ментальными картами (Mind Map, наверно, все о них слышали). Действительно, возможности Mind Map редакторов позволяют построить аналог карты аргументов.

История и концепция Assurance Case

Какое отношение имеет все это к безопасности? Чтобы ответить на этот вопрос, обратимся ко второй половине ХХ века, именно там берет свое начало современная теория и практика обеспечения безопасности. Тогда, в результате развития сложных техногенных отраслей, таких, как атомная энергетика, космическая техника, нефтегазовая и химическая промышленность, транспорт, человечество столкнулось с техногенными катастрофами невиданных ранее масштабов.

Тогда и появилась первые отчеты по анализу безопасности, в которых сводились воедино вся релевантные требования, а, также, информация, подтверждающая их соблюдение. Позже появился термин Safety Case (по сути, аналитический отчет по безопасности), который являлся предшественником Assurance Case. Отметим, что термины Safety Case или Assurance Case напрямую перевести термин на русский язык невозможно, в данном контексте, наиболее логичным переводом является обоснование безопасности. Хотя, например, в российских переводах серии стандартов ИСО/МЭК 15026 (Systems and software engineering Systems and software assurance) Assurance Case переведен, как гарантийный случай.

Следует отметить, что в некоторых отраслях термин Safety Case применяется и в настоящий момент, наравне с Assurance Case. Assurance Case, будучи более современным термином, противопоставляется Safety Case в том смысле, что на сегодняшний день система должна соответствовать не только требованиям safety (функциональная безопасность), но, также, и security (информационная безопасность). Поэтому, предлагается использовать понятие Assurance Case, а Safety Case считать его частным случаем.

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

Вернемся, однако, в ХХ век. Первым нормативным документом, требующим разрабатывать и анализировать Safety Case для потенциально опасных индустриальных объектов, стал CIMAH (Control of Industrial Major Accidents Hazards) Regulations, первоначально выпущенный в Великобритании в 1984 году, а затем адаптированный и в ряде других стран. Более широкое внедрение Safety Case в практику стало происходить после небывалой аварии на нефтяной платформе Piper Alpha в Северном море, унесшей в 1988 году жизни 167 человек.

В 1990-х годах исследователи продолжают искать новые подходы к оцениванию безопасности. Идея, вроде бы, лежит на поверхности: давайте разработаем специальную нотацию для обоснования соответствия техногенных объектов и систем требованиям по безопасности. За дело взялись две британские университетские команды, лондонский университет Сити (City, University of London), где была создана спин-офф компания Adelard, и университет Йорка (University of York). Надо сказать, что и в наши дни Adelard и университет Йорка занимают лидирующие позиции в области продвижения Assurance Case.

Для разработки нотаций упор был сделан на логическую аргументацию того, что свойство или компонент системы соответствует заявленным требованиям. В качестве теоретической основы были выбраны уже рассмотренные нами труды Стивена Тулмина. Будучи гуманитарием, Тулмин вряд ли он думал о техногенных системах, однако, в историю, он вошел, в том числе, и как основоположник аргументации для Assurance Case.

Взяв за основу, нотацию Тулмина, британцы вскоре разработали методологию Assurance Case (называемую в то время Safety Case) и довели результаты до практических индустриальных внедрений. В университете Йорка, была разработана Goal Structuring Notation (GSN), эту тему продвигал PhD студент Tim Kelly под руководством профессора John McDermid. В результате произошел тот редкий случай, когда диссертация Arguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998 уже больше 20 лет считается классическим трудом, и ее продолжают активно цитировать. Однако, подход к решению проблемы безопасности был, на мой взгляд, в большей степени академический, и, как результат, не был почему-то сделан вроде бы понятный и логичный шаг, связанный с разработкой программного средства для поддержки Assurance Case.

Adelard же, под руководством Robin Bloomfield и Peter Bishop, напротив, в первую очередь стремился к коммерциализации результатов. Параллельно с Йорком, в Лондоне была разработала нотация Claim, Argument and Evidence (CAE), а также программный инструмент Adelard ASCE (Assurance and Safety Case Environment), который поддерживает и CAE, и GSN. В Великобритании разработка Assurance Case (Safety Case) требуется законами и стандартами во многих областях, связанных с безопасностью, поэтому ASCE имеет здесь довольно устойчивый рынок. ASCE был и остается наиболее используемым инструментом разработки Assurance Case. Основной частью инструмента является графический редактор, в котором к графическим блокам может быть прикреплена дополнительная текстовая или гиперссылочная информация (Рисунок 3). Самостоятельно загрузить программное обеспечение ASCE с веб-сайта Adelard не получится. Вы должны заполнить запрос на 30-дневную пробную версию или академическую лицензию, после чего запрос будет рассмотрен компанией.


Рисунок 3. Интерфейс программы Adelard ASCE

Теперь рассмотрим две базовые нотации, применяемые для разработки Assurance Case (CAE и GSN).

Нотация CAE (Claim, Argument and Evidence)

Нотация CAE (Claim, Argument and Evidence цель, аргумент, подтверждение) оперирует тремя указанными сущностями: цели указывают на достижение требуемых свойств системы, подтверждения предоставляют документированный базис для аргументации, демонстрирующей достижение либо не достижение целей, аргументы строятся при помощи правил вывода и связывают подтверждения с целями. Обычно применяются такие аргументы, как детерминистские (или логические), вероятностные и качественные. Для обозначения целей, аргументов и доказательств вводятся графические примитивы, имеющие различную форму (Рисунок 4).

Рисунок4. Нотация Claim, Argument and Evidence (CAE): основные компоненты

Построение иерархии целей и подцелей является первым этапом разработки Assurance Case. Как показано на схеме, структура целей, аргументов и подтверждений не обязательно является трехуровневой, например, для поддержки аргументации могут использоваться дополнительные подцели. CAE нотация также легко трансформируется в табличный вид. Столбцами такой таблицы будут являться все те же цели, аргументы и подтверждения, между которыми теперь будут установлены связи в пределах табличных записей. Подобный подход к разработке Assurance Case используется, например, компанией exida.

Нотация GSN (Goal Structuring Notation)

GSN оперирует такими компонентами, как цель (goal, обозначается прямоугольником и является аналогом claim в CAE), стратегия аргументации (strategy, обозначается параллелограммом и является аналогом argument) и решение (solution, обозначается кругом и является аналогом evidence) (Рисунок5). Контекст (context) применяется для информационной поддержки целей. Для поддержки аргументации могут применяться предположение (assumptions) и обоснование (justifications). Структура целей имеет иерархический характер.


Рисунок5. Нотация Goal Structuring Notation (GSN): основные компоненты

Если сравнивать между собой CAE и GSN, то следует отметить, что CAE уделяет больше внимания обоснованию отдельных аргументов. Для этого выполняется детальное конструирование шагов аргументации. GSN больше фокусируется на типовых структурах (паттернах) аргументов. За счет большего числа сущностей, GSN является менее строгой, и, в то же время, при более лаконичном описании она может быть сведена к CAE. Применение каждой из нотаций может быть в достаточной мере субъективным, поскольку подход к конструированию аргументов зависит от лица, которое выполняет эту задачу. Некоторые практики Assurance Case отмечают, что в нотациях существует ряд пробелов, связанных с полнотой определения элементов семантики.

Сложилось так, что на сегодняшний день более распространенной является GSN. Формат GSN закреплен в стандарте Goal Structuring Notation (GSN) Community Standard, а также в метамодели данных Structured Assurance Case Metamodel (SACM) от Object Management Group (OMG).

База знаний: отрасли, стандарты, исследования, инструменты, альтернативные нотации

Assurance Case используется, в первую очередь, в тех отраслях, в которых его применение регламентировано нормативными документами. Лидером здесь является Великобритания и некоторые другие страны Британского содружества. В отчете британской Health Foundation Using safety cases in industry and healthcare (2012) говорится об опыте нормативного применения Assurance Case (Safety Case) в здравоохранении, авиации, атомной энергетике, автомобильной, оборонной, нефтехимической и железнодорожной отраслях.

Если рассматривать требования к применению Assurance Case за пределами Великобритании, то следует отметить:

• автомобильный стандарт ISO 26262:2011, Road vehicles Functional safety, входящий в семейство стандартов по функциональной безопасности, детализирующих требования МЭК 61508;
• документы European Organisation for the Safety of Air Navigation (EUROCONTROL): Safety Case Development Manual, 2006, EAD (European Aeronautical Information System Database) Safety Case, 2009, EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010;
• документированную общую позицию регулирующих организаций по ядерной безопасности в области лицензирования ПО для ядерных реакторов Licensing of safety critical software for nuclear reactors Common position of international nuclear regulators and authorised technical support organisations, 2018, согласована девятью странами (Бельгия, Германия, Канада, Испания, Корея, Китай, Великобритания, Швеция, Финляндия);
• стандарты серии ISO/IEC 15026, Systems and software engineering Systems and software assurance, которая включает четыре части: Part 1: Concepts and vocabulary (2019); Part 2: Assurance case (2011); Part 3: System integrity levels (2015); Part 4: Assurance in the life cycle (2012).
  

Также следует отметить ряд организаций (помимо уже упомянутых Adelard и High Integrity Systems Engineering Group из университета Йорка), которые активно работают в области Assurance Cases. К ним относятся:

• US-CERT (United States Computer Emergency Readiness Team), свою методологию они называют Security Assurance Cases;
• SEI/CMU (Sofrware Engineering Institute Carnegie Mellon University), в первую очередь, CERT Division, входящий в состав SEI, осуществляет исследовательскую и академическую поддержку для развития методологии Assurance Case и активно сотрудничает с US-CERT;
• NASA (National Aeronautics and Space Administration) в рамках программы Scientific and Technical Information (STI) применяет Assurance Case для оценивания безопасности беспилотников и некоторых космических аппаратов;
• среди всех академических публикаций, на мой взгляд, своей практической направленностью выделяются исследования John Rushby, выполненные по программам исследовательского института SRI International (бывший Stanford Research Institute), и особенно, отчет The Interpretation and Evaluation of Assurance Cases, к которому мы еще обратимся.

Из программных средств поддержки Assurance Case наиболее известным остается Adelard ASCE (Case Case and Safety Case Environment). Большинство проектов, упоминаемых в разные годы, так и не вышли на какой-либо серьезный уровень. NASA заявило о создании ПО AdvoCATE, но они применяют его в собственных целях, и не планируют выпускать на рынок. Учитывая простоту нотации, для составления диаграмм Assurance Case и их дополнения гиперссылками можно использовать, например, MS Visio.

Из альтернативных подходов к разработке Assurance Case можно также упомянуть программный инструмент NOR-STA. Он бы разработан польской компанией Argevide (spinoff Гданьского технологического университета). NOR-STA поддерживает собственную нотацию TRUST-IT. Разница состоит в том, что вместо графического представления NOR-STA использует структурированный иерархический список (Рисунок 6).



Рисунок6. Нотация Trust-IT: основные компоненты и пример использования

Сущности в иерархическом списке целей Assurance Case обозначаются разными значками. Для подтверждения соответствия заявлению используется стратегия аргументации, а факты или наблюдения, обоснования, предположения и дополнительные утверждения используются в качестве аналога подтверждений. В отличие от десктопного Adelard ASCE, NOR-STA используется онлайн и поддерживает распределенную командную работу.

Кроме того, Assurance Case применяется для решения следующих прикладных задач:

• оценивание атрибутов комплексных свойств, таких, как Quality, Dependability, Security;
• поддержка сертификации и стандартизации путем преобразование требований стандартов в структуру аргументов;
• Assurance Based Development (ABD) или разработка продукта, основанная на гарантиях, является разновидностью Model-Based Development (MBD);
• управление знаниями, например, моделирования структуры документации либо определение структурных связей в какой-либо области деятельности (бизнес процессы, документооборот, управления изменениями и т.д.).

Применение Assurance Case в области информационной безопасности

Security (Trustworthiness) Case известен, как одна из разновидностей Assurance Case. При необходимости, Security Case может быть дополнен компонентами Safety Case. Собственно говоря, идея Assurance Case и состоит в объединении атрибутов safety & security. В области сертификации существуют наработки для стандарта ISO/IEC 15408 (Общие критерии), для которого было выполнено преобразование требований в структуру, совместимую со структурой Assurance Case. Такое преобразование может быть выполнено и для других релевантных стандартов, например, для ISO 27000, или IEC 62443, или любых других фреймворков.

В качестве примера приведен фрагмент Security Assurance Cases, размещенный на сайте US-CERT. В этом фрагменте рассмотрено подтверждение реализации безопасного цикла разработки ПО (Software Development Life Cycle, SDLC). Фокус сделан на устранение дефектов кодирования (в частности Buffer Overflow), для чего применяются такие методы, как обучение программистов, ревью кода, статический анализ и тестирование. Можно, конечно, поспорить с полнотой этого фрагмента, но он приведен лишь в качестве иллюстрации (Рисунок 7).


Рисунок 7. Фрагмент Security Assurance Cases

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

Пример практического применения Assurance Case

И, наконец, давайте рассмотрим на примере, как это все может работать. В основу положен подход, основанный на разработке структурированных аргументов.

Структурированные аргументы

Представим процесс разработки аргументов в виде двух последовательных шагов (Рисунок 8). Первый шаг, называемый шагом рассуждения (Reasoning Step, RS), это анализ подцелей (SC), которые направлены на достижение основной цели (С). На этом шаге развивается структура аргументации. На втором шаге, называемом шагом подтверждения (Evidential Step, ES), формулируются подтверждения (Evidece, E) в поддержку подцелей (SC), выработанных на предыдущем шаге. Для дальнейшей формализации шагов RS и ES используются типовые шаблоны структурированного текста (Structured Text, ST).


Рисунок 8. Шаги и компоненты структурированных аргументов

Иерархия требований

Представим иерархию или пирамиду требований, которые образуют структуру, соответствующую графу Assurance Case. В большинстве нормативных требований к компьютерным системам или к ПО структура требований включает 3 или 4 уровня (Рисунок 9).


Рисунок 9. Иерархия требований и ее связь с шагами аргументации

Нулевой уровень это мета-цель, согласно которой оцениваемая система должна соответствовать всем требованиям безопасности. На первом уровне достигаются глобальные цели безопасности, например, из требований МЭК 61508 к функциональной безопасности вытекают следующие цели:

• должна быть реализована система управления безопасностью;
• во время разработки системы (или ПО) должен быть применен жизненный цикл безопасности;
• для системы должен быть применен достаточный комплекс мер защиты от случайных отказов;
• для системы (или ПО) должен быть применен достаточный комплекс мер защиты от систематических и программных отказов, включая защиту от кибератак.

На втором уровне группы требований поддерживают ту или иную глобальную цель. Например, требования к управлению безопасностью (согласно МЭК 61508) включают группы требований к управлению персоналом, управлению конфигурацией, управлению документацией и другие. Структура связей между нулевым, первым и вторым уровнями представляет собой достаточно простое дерево. Такая структура не требует детальной проработки аргументов, поскольку аргументы эти являются типовыми и многократно проверенными в различных проектах. Однако при переходе со второго уровня на более низкие требуются структурированные аргументы. При этом требования нижних уровней могут быть составными (то есть, включать ряд отдельных требований) или простыми (атомарными). Если все требования атомарные (составные требования отсутствуют), то данный уровень становится третьим, и тогда он напрямую связан с подгруппами требований. Если имеются составные требования, то получаем более сложную четырехуровневую структуру.

Для самого нижнего уровня, помимо RS, также следует применять ES. Поскольку неудобно добавлять подробную информацию о содержании аргументов в структуру графа, каждый из узлов графа Assurance Case, начиная со второго уровня, размечается описанием аргументов с использованием структурированного текста (ST). Граф Assurance Case на нижнем уровне уже не является деревом, потому что одно и то же подтверждение (E) может поддерживать разные подцели (SC).

Assurance Case для группы требований к управлению персоналом (МЭК 61508)

В качестве иллюстрации рассмотрим фрагмент Assurance Case применительно к требованиям МЭК 61508 к управлению персоналом (МЭК 61508-1, раздел 6).


Всего из МЭК 61508 было извлечено семь требований, связанных с управлением персоналом. С точки зрения структурированной аргументации, эти требования являются подцелями (SС1,,SС7). Лишь одна из подцелей (SС5) является составной, все остальные атомарные. Для того, чтобы перейти от составной подцели (SС5) к атомарным (SС5.1,,SC5.11), выполняется еще один шаг рассуждения (RS). При этом подразумевается, что согласно требованиям МЭК 61508, для проекта, связанного с созданием какого-либо абстрактного продукта, был разработан Human Resource Management Plan. Этот план интерпретирует требования стандарта в контексте проекта.


Для выполнения всех шагов подтверждения (ES) предлагается использовать общий структурированный текст с указанием связей между подцелями (SG) подтверждениями (E). Будем использовать отношение SG -> E, чтобы обозначить взаимосвязь между соответствующей подцелью (SG) и поддерживающими ее подтверждениями (E).


Все полученные отношения SG -> E могут быть трансформированы в граф Assurance Case, согласно нотации GSN, модифицированной для структурированной аргументации (Рисунок 10). Этот граф отражает всю группу требований, связанных с управлением персоналом согласно МЭК 61508. Также данный граф можно использовать в качестве шаблона для выполнения оценивания на соответствие требованиям МЭК 61508.


Рисунок 10. Граф Assurance Case, полученный на основе структурированных аргументов для группы требований по управлению персоналом (МЭК 61508)

На первый взгляд все это долго и сложно, но, тем не менее, Assurance Case имеет свое практическое применение. Именно такой подход мы использовали при сертификации ПЛК RdICS на соответствие МЭК 61508.

Заключение

Метод Assurance Case (Safety Case) применяется на протяжении более 20 лет для анализа безопасности объектов КИИ. Наибольшее распространение данный метод получил в Великобритании и ряде стран Британского содружества для таких отраслей, как здравоохранение, авиация, атомная энергетика, автомобилестроение, оборонная, нефтехимическая и железнодорожная промышленность.

К достоинствам Assurance Case следует отнести все плюсы, достигаемые визуализацией отношений в сложной предметной области, за счет улучшения нашего восприятия и понимания. Недостатки обусловлены субъективностью метода в части его зависимости от экспертности лиц, выполняющих оценивание. Наиболее известный epic fail в применении Assurance Case описан здесь. Вкратце: 2 сентября 2006 г. в Афганистане произошел пожар на борту самолета Nimrod Британских ВВС. Проблема возникла из-за утечки топлива. Погибли все 14 человек, находившиеся на борту. Выпущенный ранее отчет Safety Case подтверждал безопасность воздушного судна. Расследование показало, что на серийных самолетах была не вполне корректно выполнена модификация топливной системы, и подобные проблемы возникали раньше, но почему-то никто не обратил на них внимания, как на системную ошибку. В выпущенном 600-страничном отчете это происшествие было названо не иначе, как a failure of leadership, culture and priorities.

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

На сегодняшний день основным драйвером внедрения Assurance Case являются нормативные и законодательные требования, а вовсе не удобство, целесообразность или экономическая эффективность. Очевидно, что в области Assurance Case открываются большие возможности для искусственного интеллекта, но что-то мне не встречались публикации на данную тему.
Тем не менее, проблема, связанная с оцениванием безопасности сложных систем, остается открытой. Возможно, что определенный прогресс в этой области может быть достигнут при активном внедрении Assurance Case, ведь этот метод опирается на все те важные моменты, которые занимали человечество с самого начала философских исследований.

Формат RFC существует с 1969 года его представили во время обсуждения ARPANET. Тогда инженер Стив Крокер написал RFC 1 о работе программного обеспечения хоста.

С тех пор прошло более 50 лет, но Request for Comments все еще в ходу опубликовано ~9 тыс. документов по сетевым протоколам, моделям хранения данных и алгоритмам шифрования.

В этом многообразии встречаются RFC, у которых нет практического применения. Их написали по большей части ради шутки. Сегодня расскажем о некоторых находках из этой области.


Фото Braydon Anderson Unsplash

RFC 8771

Здесь описана интернационализированная сознательно нечитаемая сетевая нотация (I-DUNNO). По словам авторов, документ призван внести баланс в следующую ситуацию:

В начале 80-х была представлена DNS. Она сделала доступ к сетевым ресурсам удобнее, но инженеры по-прежнему вторгаются в сферу коммуникаций machine-to-machine: читают и вручную прописывают IP-адреса. Задача I-DUNNO воспрепятствовать этой деятельности и, наконец, закрепить работу с адресами за вычислительными системами.

I-DUNNO использует кодировку UTF-8, чтобы обфусцировать IP-адреса и усложнить их чтение для человека. Кодовые точки представлены октетами в количестве от одного до четырех, а сама последовательность включает как минимум один символ, запрещенный IDNA2008.

В качестве примера авторы RFC 8771 приводят трансформацию IPv4-адреса 198.51.100.164. Сперва его записывают в виде 32-битной строки:

11000110001100110110010010100100

Затем переводят в символьную форму:

1100011 -> U+0063 (буква c)0001100 -> U+000C (символ смены страницы form feed1101100 -> U+006C (буква l)10010100100 -> U+04A4 (кириллическая заглавная лигатура нг)

Алгоритм обратного преобразования не указан, так как компьютеры знают, что делать, а люди не должны даже пробовать.

RFC 8774

В этом документе описаны особые ошибки, которые возникнут в квантовых сетях будущего. Информация в них передается по оптоволоконным кабелям с помощью кубитов поляризованных фотонов. Автор RFC 8774 пишет, что после массового внедрения таких сетей, значение времени передачи пакета сможет равняться нулю. Этот факт приведет к сбоям в интернете, так как классическая сетевая инфраструктура и протоколы не рассчитаны на работу с таким таймингом.

К ситуации 0-RTT подготовлены лишь несколько протоколов: TFO, TLS 1.3 и QUIC. Многие другие будут работать с ошибками квантовыми багами.


Фото Umberto Unsplash

В протоколе Multipath TCP для оценки пропускной способности вычисляется значение alpha. На одном из этапов необходимо поделить на RTT, что невозможно при круговой задержке равной нулю. В свою очередь, протокол LEDBAT, используемый Apple и BitTorrent, начнет передавать пакеты максимально быстро и засорять канал, хотя должен ограничивать нагрузку на сеть.

Чтобы решить проблему, автор RFC 8774 предлагает начать с составления полного списка протоколов, подверженных квантовым багам. В качестве референса можно использовать RFC 2626 о проблеме 2000 года. Затем останется обновить весь ненадежный код. Этот процесс может затянуться, учитывая, что проблему 2038 года для Linux решали несколько лет и закончили переписывать код ядра лишь в этом году.

---

<sup>Больше интересных материалов в нашем корпоративном блоге:

Нашел, увидел, получил: необычные приглашения на собеседование
Группа разработчиков предлагает перейти на UTF-8
Как развивалась система доменных имен: эра ARPANET
Подборка книг по кибербезопасности</sup>

---

Формат RFC существует с 1969 года его представили во время обсуждения ARPANET. Тогда инженер Стив Крокер написал RFC 1 о работе программного обеспечения хоста.

С тех пор прошло более 50 лет, но Request for Comments все еще в ходу опубликовано ~9 тыс. документов по сетевым протоколам, моделям хранения данных и алгоритмам шифрования.

В этом многообразии встречаются RFC, у которых нет практического применения. Их написали по большей части ради шутки. Сегодня расскажем о некоторых находках из этой области.


Фото Braydon Anderson Unsplash

RFC 8771

Здесь описана интернационализированная сознательно нечитаемая сетевая нотация (I-DUNNO). По словам авторов, документ призван внести баланс в следующую ситуацию:

В начале 80-х была представлена DNS. Она сделала доступ к сетевым ресурсам удобнее, но инженеры по-прежнему вторгаются в сферу коммуникаций machine-to-machine: читают и вручную прописывают IP-адреса. Задача I-DUNNO воспрепятствовать этой деятельности и, наконец, закрепить работу с адресами за вычислительными системами.

I-DUNNO использует кодировку UTF-8, чтобы обфусцировать IP-адреса и усложнить их чтение для человека. Кодовые точки представлены октетами в количестве от одного до четырех, а сама последовательность включает как минимум один символ, запрещенный IDNA2008.

В качестве примера авторы RFC 8771 приводят трансформацию IPv4-адреса 198.51.100.164. Сперва его записывают в виде 32-битной строки:

11000110001100110110010010100100

Затем переводят в символьную форму:

1100011 -> U+0063 (буква c)0001100 -> U+000C (символ смены страницы form feed)1101100 -> U+006C (буква l)10010100100 -> U+04A4 (кириллическая заглавная лигатура нг)

Алгоритм обратного преобразования не указан, так как компьютеры знают, что делать, а люди не должны даже пробовать.

RFC 8774

В этом документе описаны особые ошибки, которые возникнут в квантовых сетях будущего. Информация в них передается по оптоволоконным кабелям с помощью кубитов поляризованных фотонов. Автор RFC 8774 пишет, что после массового внедрения таких сетей, значение времени передачи пакета сможет равняться нулю. Этот факт приведет к сбоям в интернете, так как классическая сетевая инфраструктура и протоколы не рассчитаны на работу с таким таймингом.

К ситуации 0-RTT подготовлены лишь несколько протоколов: TFO, TLS 1.3 и QUIC. Многие другие будут работать с ошибками квантовыми багами.


Фото Umberto Unsplash

В протоколе Multipath TCP для оценки пропускной способности вычисляется значение alpha. На одном из этапов необходимо поделить на RTT, что невозможно при круговой задержке равной нулю. В свою очередь, протокол LEDBAT, используемый Apple и BitTorrent, начнет передавать пакеты максимально быстро и засорять канал, хотя должен ограничивать нагрузку на сеть.

Чтобы решить проблему, автор RFC 8774 предлагает начать с составления полного списка протоколов, подверженных квантовым багам. В качестве референса можно использовать RFC 2626 о проблеме 2000 года. Затем останется обновить весь ненадежный код. Этот процесс может затянуться, учитывая, что проблему 2038 года для Linux решали несколько лет и закончили переписывать код ядра лишь в этом году.

---

<sup>Больше интересных материалов в нашем корпоративном блоге:

Нашел, увидел, получил: необычные приглашения на собеседование
Группа разработчиков предлагает перейти на UTF-8
Как развивалась система доменных имен: эра ARPANET
Подборка книг по кибербезопасности</sup>

---

На днях комитет ISO по стандартизации языка С++ (да, есть и такой) утвердил международный стандарт С++20. Возможности, которые представлены в спецификации, поддерживаются в компиляторах GCC, Clang и Microsoft Visual C++. Кроме того, стандартные библиотеки с поддержкой С++20 реализованы в рамках проекта Boost.

Следующий этап подготовка документа к публикации. Затем, в начале ноября, финальный вариант будет направлен в ISO, после чего он будет опубликован под формальным названием ISO/IEC 14882:2020. Сейчас комитет уже работает над следующим стандартом C++23 (C++2b). Под катом особенности С++20 с примерами кода.

Что нового?

Комитет добавил концепции, расширения шаблонов, которые позволяют определить набор требований к параметрам шаблона. Во время компиляции они ограничивают набор аргументов, которые могут приниматься в качестве параметров шаблона. Концепции дают возможность избежать логических несоответствий между свойствами типов данных, которые используются внутри шаблона, и свойствами типов данных входных параметров.

 template<typename T>   concept EqualityComparable = requires(T a, T b) {       { a == b } -> std::boolean;       { a != b } -> std::boolean;   };

Приняты расширения для работы с модулями. Их можно использовать вместо заголовочных файлов. Модули предоставляют новый способ организации исходных текстов на основании определения границ компонентов, без подключаемых при помощи "#include" заголовочных файлов.

Добавлен макрос __VA_OPT__ для адаптивного раскрытия вариативных макросов в зависимости от наличия токенов в вариативном аргументе.

Добавлена поддержка оператора <=> для трехстороннего сравнения.

Поддерживаются инициализаторы элементов по умолчанию для битовых полей.

Появилась возможность лямбда-захвата выражений *this.

   struct int_value {     int n = 0;     auto getter_fn() {       // BAD:       // return [=]() { return n; };        // GOOD:       return [=, *this]() { return n; };     }   }; 

Для классов теперь можно использовать параметры шаблона без типа.

   struct foo {     foo() = default;     constexpr foo(int) {}   };    template <foo f>   auto get_foo() {     return f;    }    get_foo(); // uses implicit constructor   get_foo<foo{123}>();

Появилась возможность использования строковых литералов в параметрах шаблона. Поддерживается синтаксис инициализации в стиле Си. Те, что явно не перечисляются в списках инициализации поля, инициализируются по умолчанию.

struct A {     int x;     int y;     int z = 123;   };    A a {.x = 1, .z = 2}; // a.x == 1, a.y == 0, a.z == 2

Поддерживаются пустые члены структур данных.

Поддерживаются атрибуты likely и unlikely для информирования оптимизатора о вероятности срабатывания условной конструкции ("[[likely]] if (random > 0) {").

Появилась возможность использования диапазонов для инициализации значений переменной в цикле for

   for (auto v = std::vector{1, 2, 3}; auto& e : v) {

Поддерживаются immediate функции, которые могут работать только с константами.

 consteval int sqr(int n) {     return n * n;   }    constexpr int r = sqr(100); // OK   int x = 100;   int r2 = sqr(x); // ERROR:  'x' не может использоваться как константа

В библиотеку добавлены:

• поддержка типа char8_t для строк UTF-8.
• заголовочные файлы bit (битовые операции) и version.
• возможность проверки префикса и суффикса строк (starts_with, ends_with).
• типажи std::remove_cvref, std::unwrap_reference, std::unwrap_decay_ref, std::is_nothrow_convertible и std::type_identity.
• функции std::midpoint, std::lerp, std::bind_front, std::source_location, std::visit, std::is_constant_evaluated и std::assume_aligned.
• поддержка массивов в std::make_shared.
• функция std::to_array для преобразования похожих на массив объектов в std::array.

Синтаксис перечислений теперь более удобен:

   enum class rgba_color_channel { red, green, blue, alpha };    std::string_view to_string(rgba_color_channel my_channel) {     switch (my_channel) {       using enum rgba_color_channel;       case red:   return "red";       case green: return "green";       case blue:  return "blue";       case alpha: return "alpha";    }   }

В индексах запрещено использовать операции "," (a[b,c]). Большинство операций с переменными, объявленными с ключевым словом violate, включая запрещенные операции "++" и "--" со стандартными типами, не поддерживаются.

Если вкратце: потому что мы так сказали.

:)

Ладно, это слишком короткое объяснение для статьи, дорогой читатель, и мои провокационные слова требуют объяснения.

Встреча Комитета по языку С которую сначала планировали провести в германском Фрайбурге, но не срослось по понятным причинам, завершилась 7 августа. Она прошла хорошо, мы продвинулись по всем фронтам. Да, мы действительно продвигаемся, уверяю вас, и язык С не умер.

Ещё упомяну, что я стал Редактором проекта по С, так что прежде чем воспринимать заголовок как неосведомлённое высказывание человека, который слишком ленив, чтобы стараться улучшать, хочу заверить вас, что я на самом деле очень много работаю над тем, чтобы С мог удовлетворять потребностям разработчиков без необходимости прикручивать 50 специфических расширений ради сборки мало-мальски красивых и полезных библиотек и приложений.

И всё же я это сказал (что язык С никогда не помешает вам делать ошибки), а значит должен обосновать. Можем посмотреть на тысячи CVE и связанные с ними тикеты с кучей кода на С. Либо можем привлечь MISRA, чтобы она энергично проверяла каждую, даже самую мелкую фичу С на возможность неправильного использования (привет, объявления прототипа K&R) или наличие более сложных и забавных ошибок, относящихся к портируемости и неопределённому поведению. Но вместо этого почитаем первоисточник что сказал сам Комитет.

О, пора брать попкорн?!

Нет, дорогой читатель, отложи попкорн. Как и в случае со всеми процедурами ISO, я не могу цитировать чьи-либо слова, и эта статья не для того, чтобы покрывать кого-то позором. Но я объясню, почему то, что мы легко можем посчитать плохим поведением в соответствующем стандартам документе ISO C, никогда не будет исключено. И начнём с документа за авторством доктора Филиппа Клауса Краузе (Dr. Philipp Klaus Krause):

N2526, используйте const для библиотечных данных, которые не будут модифицированы.

N2526 очень простой документ.

Некоторые данные, возвращаемые библиотекой, являются константами нравственно, по духу и даже по своей реализации. Записывать в них это ошибка и неопределённое поведение, так что давайте перестанем дразнить друг друга и окольцуем этого шалуна!

Согласен, говорится не совсем о том же, но я уверен, что идея покажется тебе разумной, дорогой читатель. Когда этот документ поставили на голосование, против него почти не было голосов. Позднее несколько человек сильно возразили, потому что это предложение ломало старый код. Конечно, это плохо: даже у меня перехватывает дыхание, когда я задумываюсь, добавлять ли const? В языке С нет ABI, на который может повлиять нововведение. С (его реализации) даже не обращает внимание на квалификаторы (qualifier), как же мы можем что-то поломать?! Давайте разберёмся, почему некоторые считают, что это будет критическим изменением.

Язык С

Или, как мне нравится называть его, Типобезопасность это для языков-неудачников. Да, слишком многословно, так что остановимся на С. Возможно, вы удивились, почему я говорю, что в языках вроде С нет типобезопасности. Ведь вот же:

struct Meow {    int a;};struct Bark {    double b;    void* c;};int main (int argc, char* argv[]) {    (void)argc;    (void)argv;    struct Meow cat;    struct Bark dog = cat;    // error: initializing 'struct Bark' with an expression of incompatible type 'struct Meow'    return 0;}

Буду честен: для меня это выглядит как сильная типобезопасность, Джим! А так всё становится ещё пикантнее:

#include <stdlib.h>struct Meow {    int a;};struct Bark {    double b;    void* c;};int main (int argc, char* argv[]) {    (void)argc;    (void)argv;    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));    struct Bark* p_dog = p_cat;    // :3        return 0;}

Да, стандарт С позволяет двум совершенно независимым типам указателей ссылаться друг на друга. Большинство компиляторов предупредят об этом, но стандарт требует принимать этот код, если только вы не раскрутите -Werror -Wall -Wpedantic и т.д., и т.д., и т.д.

На самом деле, компилятор может без явного приведения типов принимать вот что:

• volatile (кому вообще нужны эти семантики?!)
• const (записывайте сюда любые данные только для чтения!)
• _Atomic (потокобезопасность!)

Я не хочу сказать, что вы не должны иметь возможности всё это делать. Но когда пишешь на С в котором очень легко создать функцию на 500-1000 строк с совершенно непонятными именами переменных, Инфа Сотка, что вы работаете преимущественно с указателями, и вам вообще не хватает безопасности в том, что касается базового языка. Примечание: это нарушает ограничения, но уже написано столько старого кода, что каждая реализация каким-либо образом игнорирует квалификаторы, и из-за этого вашему коду не помешают компилироваться (спасибо, @fanf!)! В этой ситуации можно с помощью компилятора легко определить каждый потенциальный сбой, и вы получите предупреждения, но от вас не потребуют приводить типы ради того, чтобы вы дали компилятору понять, Что Вы Действительно Хотели Так Сделать. Хотя гораздо важнее то, что при этом человеческие существа, которые придут после вас, тоже не будут понимать, что вы намеревались сделать.

Всё, что нужно сделать, это убрать возможность -Werror -Wall -Wpedantic, и вы будете готовы к совершению преступлений, связанных с многопоточностью, режимом только для чтения и аппаратными регистрами.

Теперь всё честно, верно? Если кто-то уберёт все эти предупреждения и флаги об ошибках, их не будет заботить, какие оплошности или глупости вы совершите. А это значит, что в конце концов эти предупреждения совершенно не имеют отношения к делу и безвредны в том, что касается соответствия стандарту ISO C. И всё же

Мы рассматриваем критические изменения в предупреждениях

Да.

Это специальный ад, к которому привыкли С-разработчики и в меньшей степени С++-разработчики. Предупреждения раздражают, и, как показывает практика включения -Weverything или /W4, раздражают очень сильно. Скрытие предупреждений о переменных в глобальном пространстве имён (спасибо, теперь все заголовки и С-библиотеки превратились в проблему), использование зарезервированных имён (как говорят дети, lol nice one xd!!), а также эта структура обладает паддингом, потому что вы использовали alignof (да, да, я знаю, что у неё есть паддинг, я явно попросил увеличить паддинг, ПОТОМУ ЧТО Я ИСПОЛЬЗОВАЛ alignof, МИСТЕР КОМПИЛЯТОР) всё это отнимает кучу времени.

Но это же предупреждения.

Даже если они раздражают, они помогают избежать проблем. Тот факт, что я могу беззастенчиво игнорировать все квалификаторы и пренебрегать всеми видами безопасности чтения, записи, потоков и режима только для чтения, является серьёзной проблемой, когда речь заходит о сообщении своих намерений и предотвращении багов. Даже старый синтаксис K&R приводил к багам в промышленных и правительственных кодовых базах, потому что пользователи делали что-то неправильно. И делали они так не потому, что паршивые программисты, а потому, что работают с кодовыми базами, которые зачастую старше них, и готовятся биться с тех. долгом размером в миллионы строк. Невозможно удержать в голове всю кодовую базу: для этого предназначены соглашения, статический анализ, высокоуровневые предупреждения и прочие средства. К сожалению,

всем хочется иметь код Без Предупреждений.

Это означает, что когда GCC-разработчик делает предупреждения более чувствительными к потенциально проблемным ситуациям, мейнтейнеры (не исходные разработчики) неожиданно получают от старого кода жирные логи на несколько гигабайтов, содержащие массу новеньких предупреждений и всякого разного. Это идиотизм, говорят они, код работал ГОДАМИ, так почему GCC теперь жалуется?. То есть, даже если добавить const в сигнатуру функции, даже если это нравственно, по духу и фактически правильно, этого будут избегать. Ломать людей означает теперь они должны искать код, у которого сомнительные намерения. Это код, который может под страхом Неопределённого Поведения рушить ваш чип или повреждать вашу память. Но это уже другая проблема, сопутствующая профессии С-разработчика в наши дни.

Возраст как мера качества

Сколько людей хотя бы предполагали, что у sudo была такая примитивная уязвимость, как -1 или целочисленное переполнение даёт доступ ко всему? Сколько людей думали, что Heartbleed может стать настоящей проблемой? Сколько разработчиков игр отгружают маленькие stb-библиотеки, даже не применив к ним фазер и не понимая, что эти библиотеки содержат больше важных входных уязвимостей, чем можно представить? Я не критикую все эти разработки или их авторов: они оказывают нам жизненно важную помощь, от которой мир зависел десятилетиями, зачастую практически без чье-либо поддержки, пока не возникала какая-нибудь большая проблема. Но люди, которые боготворят эти разработки и ставят их у себя, потом источают из себя ядовитую поговорку, иллюстрируя ошибку выжившего:

Этот код такой старый и его использует столько людей, какие в нём могут быть проблемы?

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

К сожалению, всё не так романтично и мило: кишащие багами, с обилием дыр в безопасности, весь этот технический долг с каждым днём становится опаснее. Все системы со временем превращаются в полуживые, неухоженные и частично не поддерживаемые гниющие кучи. Их приукрашивают и наделяют духом благородства, но на самом деле это мумии, которые просто ждут, когда их неловко ткнут, и тогда их гнойные, допотопные нарывы взорвутся и зальют ваше приложение своим прекрасным выдержанным ботулизмом.

Мда отвратительно. Но что насчёт Стандарта C?

Проблема, которую я заметил во время моего (невероятно короткого) пребывания в роли участника встречи, заключается в том, мы ставим во главу угла обратную совместимость. Для тех, кто даже сегодня переходит на С, мы держимся за старые приложения и сценарии их применения и лишаем себя возможности улучшить безопасность, защищённость или искусность кода на С. Предложение доктора Краузе настолько лаконично, что практически бесспорно: если кому-то не нравятся предупреждения, он может их отключить. Эти предупреждения, а не ошибки, появляются не зря: абстрактная машина С не требует проводить диагностику, ISO C позволяет принимать такой код в строгих режимах сборки. И это помогло бы всему миру оторваться от API, которые открыто заявляют: изменение содержимого, которое мы вам предоставляем, является неопределённым поведением.

И всё же мы поменяли своё мнение об этом документе после того, как в качестве причины было названо мы не можем вводить новые предупреждения.

Аргумент против предложения звучал так: написано так много кода, который сломается, если мы изменим эти сигнатуры. Это, повторюсь, ограничивает изменения в предупреждениях с точки зрения нарушения поведения (не забывайте, неявные преобразования, убирающие квалификаторы даже _Atomic полностью валидны по мнению ISO C, даже если они нарушают ограничения). Будь это так, каждый автор компилятора вводил бы что-то вроде Эпох в Rust, Только Для Предупреждений, чтобы дать людям стабильный эталонный набор для тестирования. Это предложение не ново: я читал подобные документы от инженеров Coverity о генерировании новых предупреждений и реакции пользователей на них. Трудно управлять уверенностью разработчиков относительно новых предупреждений и прочего. Приходится долго убеждать людей в их полезности. Даже Джону Кармаку пришлось потрудиться, чтобы получить от своих инструментов для статического анализа нужный набор предупреждений и ошибок, подходящий для его разработки, прежде чем он пришёл к выводу, что безответственно это не использовать.

И всё же мы, Комитет, не согласились добавить const в четыре функции, возвращающие значения, потому что это добавило бы предупреждения в потенциально опасный код. Мы возражали против того, чтобы старый синтаксис K&R признали нерекомендуемым, несмотря на веские доказательства как невинных оплошностей, так и серьёзных уязвимостей, возникающих при передаче неправильных типов. Мы почти добавили в предпроцессор неопределённое поведение, просто чтобы костьми лечь, но сделать так, чтобы реализация С вела себя как нужно. Из-за обратной совместимости мы всегда ходим по краю, чтобы не сделать очевидных ошибок. И это, дорогой читатель, пугает меня больше всего касательно будущего С.

Стандарт С не защищает вас

Не заблуждайтесь: не имеет значения, что говорят вам программисты или что вам нашёптывают. Управляющий Комитет по языку С действует очень ясно. Мы не добавим в ваш старый код новые предупреждения, даже если этот код может быть опасен. Мы не будем удерживать вас от ошибок, потому что это может пошатнуть представление о работе вашего старого кода, а это неправильно. Мы не будем помогать новичкам писать более качественный код на С. Мы не будем требовать, чтобы ваш старый код соответствовал какому-либо Стандарту. Каждая новая фича будет опциональной, потому что мы не можем представить, чтобы мы заставляли авторов компиляторов держаться более высокого стандарта или ожидали большего от разработчиков нашей стандартной библиотеки.

Мы позволим компилятору врать вам. Мы будем врать вашему коду. А когда всё пойдёт не так возникнет ошибка, ой фигня какая-то случилась, произойдёт утечка данных, мы будем торжественно качать головой. Мы поделимся своими идеями и помолимся за вас, и скажем: ну, стыд-то какой. И правда, стыд

Возможно, когда-нибудь мы это исправим, дорогой читатель.

25 лет назад, в июле 1995 года, представители немецкого Института интегральных микросхем Фраунгофера (Fraunhofer-Institut fr Integrierte Schaltungen, сокращенно Fraunhofer IIS, FIIS) приняли важное решение: использовать расширение .mp3 для обозначения нового стандарта кодирования данных. Дату этого события и принято считать днем рождения MP3.

Формат был создан для передачи аудиофайлов по медленным сетям коммуникаций, изначально телефонным. В 1995 году существовали и другие стандарты, но с их помощью звуковые файлы нельзя было сжимать настолько же эффективно, как это позволял делать MP3. Он сделал возможным бурное развитие медиаиндустрии, включая разработку цифровых плееров.

Когда горы были высокими, а компьютеры медленными

^{Источник: hackaday.com}

На самом деле, 25 лет назад появилось именно расширение для файлов, закодированных по новому стандарту. А вот его разработка стартовала гораздо раньше.

В 1977 году молодой ученый Карлхайнц Бранденбург из института Эрлангена-Нюрнберга им. Фридриха-Александра ( Friedrich Alexander Universitt, или FAU) занялся поиском методов сжатия аудио. Через пять лет его научный руководитель попросил помочь запатентовать технологию передачи музыкальных данных через телефонные линии. Сейчас это звучит странно, но в патентном бюро им отказали, объяснив отказ невозможностью реализации технологии.



Еще через три года институт, где работал ученый, получил мощные компьютеры. И у исследователей, которые имели доступ к этим машинам, появилась возможность проводить сложные вычисления, включая эксперименты со звуком. Бранденбург достиг определенных успехов в сжатии звука и в итоге получил патент на свое изобретение.

По рассказам самого Бранденбурга, он экспериментировал с одной и той же песней Tom's Diner Сюзанны Веги. Это была его любимая композиция, которая осталась таковой даже после прослушивания трека около 1000 раз. В итоге удалось найти приемлемый способ сжатия аудио, выбросив все то, что человеческое ухо просто не способно воспринять. Качество от этого страдает не сильно, а вот файл на выходе получается очень небольшим в сравнении с результатами других способов сжатия.

Путь к успеху

^{Источник: Википедия}

В 1992 году технология MPEG Layer 3 все еще не была популярной. Тем не менее, ее подготовили к коммерческому использованию, она также стала стандартом ISO. На тот момент в ходу был MPEG Layer 2, который считали отличной технологией. Бизнес не рассматривал MP3 как перспективную альтернативу существующим решениям.

Для того, чтобы решить эту проблему и обратить внимание пользователей на новый стандарт, создатель MP3 с коллегами решил провести эксперимент по передаче аудиофайла по интернету. Технология передачи была разработана, и эксперимент прошел удачно. В опыте приняла участие компания Telos Systems из Кливленда.

Но, как оказалось, все это были мелочи. Настоящий успех пришел позже, после того как разработчики выложили кодировщик в сеть. Он позволял закодировать в MP3 аудио продолжительностью всего в минуту. Но один из энтузиастов, скачавших кодировщик, смог взломать утилиту и получил возможность сжимать аудио любой длины.

После этого MP3 очень быстро стал востребованным форматом, поскольку он позволял интернет-сообществу передавать композиции по dial-up. Затем появился Napster, а вместе с ним так называемое цифровое пиратство. Музыканты стали распространять свои записи по сети, любители музыки беспрепятственно обменивались любой музыкой в любом объеме, сколько позволяла сеть. В 2001 году Стив Джобс представил iPod, который был способен хранить рекордные 1000 музыкальных композиций.

После музыкальная индустрия стала бороться со свободным обменом музыкой, что спровоцировало рост популярности стриминговых музыкальных сервисов. И все это стало возможным благодаря изобретению Карлхайнца Бранденбурга и его коллег.

Чем занимается Бранденбург сейчас?

^{Источник: brandenburg-labs.com}

После 20 лет работы в своем институте Карлхайнц Бранденбург ушел на пенсию. Исследователь не забросил любимое дело, он продолжает работать со звуком, только направление сменил. Ученый основал компанию Brandenburg Labs и работает на созданием новой технологии PARty.

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

What would whip the llamas ass?

^{Источник: ianimal.ru}

Да, а вы знаете, что Winamp сейчас доступен бесплатно? Если не знали, то теперь да. Наслаждайтесь.

Национальный институт стандартов и технологий США основали 3 марта 1901 года, сначала как Национальное бюро стандартов, и переименовали в 1988 году. Правительство поручило этой организации гарантировать единообразие мер и весов по всем США, и помогать промышленности, учёным и всем прочим с выработкой стандартов.

Одна из основных задач НИСТ выпуск и продажа Справочных материалов по стандартам, СМС. В них дан широкий спектр стандартов, от проб стали и бетона до геологических материалов типа глины. Существуют стандарты и для еды. Да, в США можно купить баночку стандартного арахисового масла от НИСТ хотя её стоимость вряд ли сможет конкурировать с тем, что предлагают в обычных магазинах. Давайте разберёмся, почему существует эта стандартная еда, и что стоит на полках национального института стандартов.

Знакомимся с мерами

НИСТ выпускает порядка 1300 различных СМС, и 45 из них относятся к еде и напиткам. Наиболее известны они своим арахисовым маслом оно прославилось, когда фотография доктора Кэролин Бёрдетт, пробующей материал на вкус, стала вирусной.



Перечень стандартов огромен, хотя большая их часть будет невкусной к примеру, мясной гомогенат или детская порошковая еда.


Различные примеры из СМС от НИСТ из раздела еды и напитков

Забавно представлять себе, как правительственная организация создаёт стандартное арахисовое масло, чтобы править ими всеми, которое должно быть не лучше и не хуже того, что можно ожидать от этого продукта. Однако эти стандарты не инструкция для производителей по тому, как делать еду. Это инструменты для калибровки тестов.

Производителям нужно подтвердить как питательность еды, так и безопасность, а также отсутствие в ней опасных примесей. Для этого нужно провести несколько сложных тестов. Чтобы подтвердить надёжность этих тестов, нужно иметь под рукой стандартный, проверенный материал. Если, к примеру, вы испытываете стандартный яблочный сок от НИСТ, и уровень мышьяка в нём соответствует указанному, то вы можете быть уверены в том, что когда вы измеряете продукт вашей компании, вы получите надёжные данные.


Детская еда относительно простой предмет для испытаний, а смесь Typical Diet будет сложнее проверить.

Технически стандартная еда от НИСТ съедобна, однако она не предназначена для употребления внутрь, а стоит на несколько порядков больше, чем вы привыкли платить за еду в магазине. Упаковка из трёх баночек стандартного арахисового масла обойдётся вам в $881 без доставки, как и пять батончиков шоколада для кондитерских изделий. Купоны на праздники НИСТ тоже не раздаёт. Если бы мы хотели организовать пикник исключительно на основе СМС, мы бы выбрали молоко и яичный порошок, а также муку, чтобы выпечь батон хлеба. Для начинки мы бы взяли устриц (халява: $672 за 25 грамм), говяжью печень или, возможно, молотый шпинат для вегетарианцев.

В целом, эти справочные материалы играют важную роль в поддержании качества еды и напитков, которые мы ежедневно употребляем, на должном уровне. А вместе с формальной бледной эстетикой этикетов эти продукты прекрасно подойдут на роль прикола для холодильника хотя и обойдутся дороговато. Работа НИСТ облегчает жизнь производителей, и помогает выдавать качественную продукцию для потребителей. Поэтому загадочные справочные материалы по стандартам играют важную роль в индустрии еды и напитков.

Многое было сказано о форматах самих qr-кодов, но не менее важно то, что кодирует сам штрих-код. Как правило, qr-коды кодируют какой-то текст, однако этот текст может содержать различные команды для сканера, которые, например, сообщают ему, что закодированный текст это ссылка и что ее необходимо открыть в браузере.

В qr-коды можно закодировать самый различный текст с указаниями для сканера, как этот текст интерпретировать и какую информацию показать пользователю. Например, в qr-код можно закодировать контактную информацию с командой добавить ее в контакты телефона. Однако, чтобы каждый сканер мог понять, какой тип информации и какие команды зашифрованы, нужны стандарты.

В этой статье будут рассмотрены некоторые из этих стандартов и описаны возможные типы данных, которые можно спрятать в qr-код.

Все примеры были протестированы с помощью сканера в IOS 14 и the-qrcode-generator.com

Ссылка

Наиболее распространенным применение qr-кода это кодирование ссылок. Для этого просто закодируйте текст ссылки в qr-код. Добавьте протокол https:// в начало ссылки, чтобы убедиться, что сканер распознает текст именно как ссылку.

Пример qr-кода с ссылкой

В дикой природе встречается префикс urlto:. Кодируемый текст тогда выглядит, как urlto:habr.com. Однако данный формат поддерживается не всеми современными сканерами (например, не работает во встроенном в IOS 14)

Адрес электронной почты

Чтобы закодировать адрес электронной почты, например info@habr.com. Нужно дополнить адрес до ссылки ( подробнее про URI scheme ), которая будет распознана, как команда открыть приложение почты: mailto:info@habr.com. Добавляя параметры к ссылке, можно указать тему письма, его содержание и многое другое. Стандарт mailto RFC 6068 является частью интернет стандартов IETF.

Поэкспериментировав, можно понять, что умный сканер в IOS 14 распознает просто закодированный email и предлагает написать на него письмо. Однако, чтобы указать другие параметры, уже потребуется mailto: префикс.

# Только адрес получателя (распознается как почта в сканере IOS 14)someone@habr.com# С использованием mailto схемыmailto:someone@habr.com# Адрес и тема письмаmailto:someone@habr.com?subject=Hello%20from%20Habr# Получатель, сс: копия, bcc: скрытая копия и тема письмаmailto:someone@habr.com?cc=someoneelse@habr.com,another@habr.com,me@habr.com&bcc=lastperson@habr.com&subject=Big%20News# Адрес, CC, BCC, тема и текст письмаmailto:someone@habr.com?cc=someoneelse@habr.com,another@habr.com,me@habr.com&bcc=lastperson@habr.com&subject=Big%20News&body=QR-code%20are%20cool.

Важно заметить, что любые небуквенные символы в ссылках нужно переводить в специальный формат.

Номер телефона

Чтобы закодировать номер телефона, нужно использовать tel url-схему. Чтобы гарантировать правильность распознавания номера, лучше указывать полную версию номер (например, код страны + код города + номер).

Как и с адресом электронной почты, просто закодированный номер телефона распознается в сканере IOS 14.

# Только номер+78005553535# Tel url-схемаtel:+78005553535                                            

Контактная информация

Для передачи контакта существует несколько форматов:

• NTT DoCoMo MECARD

  
  

  Этот формат похож на предыдущие, но уже не является ссылкой.

  
  

  MECARD:N:Owen,Sean;ADR:76 9th Avenue, 4th Floor, New York, NY 10011;TEL:12125551212;EMAIL:email@example.com;;                                                    
  

  
  

  Вначале идет префикс с указанием формата MECARD, после двоеточие через точку с запятой перечисляются параметры в формате {ключ}:{значение}. В конец добавляется еще одна точка с запятой.

  
  

• BIZCARD (документации по этому стандарту я не смог найти)

  
  

  BIZCARD:N:Sean;X:Owen;T:Software Engineer;C:Google;A:76 9th Avenue, New York, NY 10011;B:+12125551212;E:email@google.com;;
  

  
  

  Синтаксис похож на предыдущий формат

• vCard

  
  

  Большинство устройств поддерживают этот формат. Однако у него существует несколько различных версий, отличающихся набором допустимых параметров.

  
  

  BEGIN:VCARDN:Smith;John;TEL;TYPE=work,VOICE:(111) 555-1212TEL;TYPE=home,VOICE:(404) 386-1017TEL;TYPE=fax:(866) 408-1212EMAIL:smith.j@smithdesigns.comORG:Smith Designs LLCTITLE:Lead DesignerADR;TYPE=WORK,PREF:;;151 Moore Avenue;Grand Rapids;MI;49503;United States of AmericaURL:https://www.smithdesigns.comVERSION:3.0END:VCARD                                                    
  

  
  

  Некоторые из доступных параметров описаны в таблице ниже.

  
  

  Ключ	Тип	Description	Format
  BEGIN	Обязательный	Все vCards должный начинаться с этого параметра	BEGIN:VCARD
  N	Опциональный	Полное имя	N:Smith;John;
  TEL;TYPE	Опциональный	Номера телефонов и их типы	TEL;TYPE=work,VOICE:(111) 555-1212 TEL;TYPE=home,VOICE:(404) 386-1017 TEL;TYPE=fax:(866) 408-1212
  EMAIL	Опциональный	Адрес электронной почты	EMAIL:smith.j@smithdesigns.com
  ORG	Опциональный	Название компании	ORG:Smith Designs LLC
  TITLE	Опциональный	Должность	TITLE:Lead Designer
  ADR; TYPE	Опциональный	Домашний и рабочий адреса в формате: Street; City; State; Postal Code; Country	ADR;TYPE=WORK,PREF:;;151 Moore Avenue;Grand Rapids;MI;49503;United States of America
  URL	Опциональный	Веб-сайт	URL:https://www.smithdesigns.com
  VERSION	Обязательный	Версия vCard	VERSION:3.0
  END	Обязательный	Закрывающий параметр	END:VCARD

SMS

Для отправки смс существует формат со url-схемой sms:, похожей на отправку email.

# Отправить смс на номерsms:+15105550101# Отправить определенный текстsmsto:+15105550101:hello there                                            

Формат smsto: является аналогом sms:, но только с помощью него мне удалось передать текст сообщения (все тесты проводились на IOS 14).

FaceTime

В документации IOS есть информация о url-схемах для доступа к звонкам FaceTime

Пример qr-кода с вывозом FaceTime

# FaceTime видео-звонокfacetime:+18005551212facetime:me@icloud.com# FaceTime аудио-звонокfacetime-audio:+18005551212facetime-audio:me@icloud.com                                           

Карты

Для передачи точки на карте используется geo: url схема. Через запятую перечисляются широта, долгота и опционально высота над уровнем моря (в метрах).

# Координатыgeo:40.71872,-73.98905# Координаты + высотаgeo:40.71872,-73.98905,100

Однако более современным способом являются простые ссылки, генерируемые самим приложением Карты. В этом случае доступно больше параметров.

# Apple mapshttps://maps.apple.com/place?address=400%20Broad%20St,%20Seattle,%20WA%20%2098109,%20United%20States&auid=17457489312301189071&ll=47.620521,-122.349293&lsp=9902&q=Space%20Needle# Google mapshttps://maps.google.com/?address=400%20Broad%20St,%20Seattle,%20WA%20%2098109,%20United%20States&auid=17457489312301189071&ll=47.620521,-122.349293&lsp=9902&q=Space%20Needle

События в календаре

iCalendar формат используется для хранения календарей. Компонент vEvents отвечает за хранения событий, он и используется для кодирования в qr-код.

BEGIN:VEVENTUID:19970901T130000Z-123401@example.comDTSTAMP:19970901T130000ZDTSTART:19970903T163000ZDTEND:19970903T190000ZSUMMARY:Annual Employee ReviewCLASS:PRIVATECATEGORIES:BUSINESS,HUMAN RESOURCESEND:VEVENT                                            

WiFi сети

После сканирование такого qr-кода устройство (Android, iOS 11+) предложит подключиться к сети.

Пример qr-кода для подключения к WiFi

WIFI:T:WPA;S:mynetwork;P:mypass;;                                            

Другие параметры приведены в таблице ниже

Недавно в рамках статьи про создания телеграм ботов, я сделал бота для генерации WiFi qr-кодов. Можете воспользоваться им, чтобы без труда создать WiFi qr-код и больше не мучиться с перепечатыванием длинных паролей.

Telegram

У телеграма есть своя url-схема, которая позволяет делиться ссылками.

# Простая ссылкаhttps://t.me/share/url?url={url}&text={text}https://telegram.me/share/url?url={url}&text={text}# Команда для приложенияtg://msg_url?url={url}&text={text}                                            

Подробнее про возможности поделиться через телеграм можно почитать в документации.

Выводы

Многие приложения имеют url-схемы, которые дают возможность обращаться к ним по ссылкам. Эти ссылки, в свою очередь, можно спрятать в qr-коды. Однако для некоторых типов данных были разработаны собственные текстовые форматы, которые подходят для сохранения в qr-коды.

Источники

• CSS-Tricks: Mailto Links

• Apple URL Scheme Reference: Mail Links

• Android: Common Intents: Mail Links

• RFC 6068 The mailto URI Scheme

• CSS-Tricks: The Current State of Telephone Links

• Apple URL Scheme Reference: Phone Links

• Android: Common Intents: Phone Links

• CSS-Tricks: iPhone Calling and Texting Links

• Apple URL Scheme Reference: SMS Links

• Apple URL Scheme Reference: FaceTime Links

• Android: Common Intents: SMS Links

• RFC 5724 URI Scheme for Global System for Mobile Communications (GSM) & Short Message Service (SMS)

---

Облачные серверы от Маклауд быстрые и безопасные.Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

25 февраля Яндекс.Практикум проводит открытый вебинар Стандарт С++20. Приглашаем разработчиков С++, которые хотят использовать последние возможности языка, а также программистов на других языках, которые хотят узнать, какие преимущества даёт разработка на C++.

На вебинаре максимально кратко и содержательно расскажем о новых фичах Стандарта: зачем они нужны, насколько они круты, когда и для чего их можно будет использовать в своих программах. Особое внимание уделим модулям, концептам, диапазонам (Ranges), корутинам и трёхстороннему сравнению. Также поговорим и об остальных нововведениях.

Вебинар будет состоять из двух частей: 70 минут обзор новых возможностей, 20 минут ответы на вопросы.

В программе

1. Краткая история Стандартов. Что привело к C++20.
2. Модули как новая эпоха языка:
   Долгожданный документ принят панацея или ошибка?
   Как С++ преодолевает 30-летнее отставание.
   Как сломать систему сборки.
3. Оператор космического корабля:
   Один за шестерых, но это ещё не всё.
   Порядки в C++ выходят на новый уровень.
4. Концепты и констрейнты. Средство от криптографических ошибок на 10000 строк или нечто большее?
5. Ranges. Просто адекватная замена парам итераторов или новый стиль в программировании?
6. Корутины:
   Что это, и почему их время ещё не пришло.
   Как сломать отладчик.
7. Приятные и важные мелочи. Краткий обзор других фич Стандарта:
   Designated initializers, инициализаторы в Ranged-for, span, календарь, format, шаблонные лямбды и другое.
   Что ещё дал нам C++20.
8. Будущее. Чего ожидать от C++ дальше.

Ведущий

Вебинар проведёт Георгий Осипов автор факультета Разработчик C++ в Яндекс.Практикуме, разработчик в Лаборатории компьютерной графики и мультимедиа ВМК МГУ.

Вебинар пройдёт 25 февраля в 19.30 (Мск).
Бесплатная регистрация.

Сап, котятки.

Я пришёл рассказать о проекте UAVCAN новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Communication And Networking (несложные бортовые сети и коммуникации уровня приложения).

В этой публикации объясняется текущее положение дел и тренды в области сложных бортовых систем, существующие и грядущие проблемы, как мы их решаем, и каких успехов добились. Во второй части, которая будет опубликована позднее, наши коллеги из Университета Иннополис подробно осветят практическую сторону внедрения UAVCAN на примере конкретных проектов.

Конъюнктура

Первый блин проекта был заложен в 2014-м. С самого начала это был эксперимент в минимализме: возможно ли в разработке сложных распределённых бортовых систем опираться на мощные абстракции, избегая при этом роста сложности реализации и связанных с ним трудностей валидации и верификации.

Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности. Когда мы говорим "бортовая система", мы подразумеваем совокупность автоматики, необходимой для реализации базовых функций транспорта; например, БСУ/ЭДСУ летательных аппаратов, всевозможные ЭБУ в автомобиле, полётный контроллер в дроне или космическом аппарате, сенсоры (радары, камеры), датчики, исполнительные механизмы, и т.п.

Бортовая электроника (электрика) автомобиля конца 20-го века может быть исчерпывающе описана довольно тривиальной схемой; вот, например, схема ВАЗ 21099:

Схема демонстрирует нам довольно непосредственный подход к организации внутрисистемных взаимодействий: есть компонент вот к нему провод. Поведения, выходящие по сложности за рамки простейших аналоговых или дискретных соотношений (нагрелась вода в системе охлаждения включился вентилятор; коленчатый вал достиг определённого угла сработало зажигание в цилиндре), не могут быть эффективно описаны и созданы на столь низком уровне ввиду когнитивных ограничений человеческого мозга. Приведённую схему легко понять, но будет ли это верно, если мы добавим электронное зажигание, круиз-контроль, а то и автопилот пятого уровня?

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

Абстракции позволяют нам обойти когнитивное ограничение на количество сущностей, единовременно удерживаемых в сознании. В теории систем этот принцип известен как "чёрный ящик". Любой человек, хоть раз державший в руках компилятор, знает, как это работает: сложные подсистемы описываются не непосредственно, а в виде ограниченных функциональных блоков со строго определённым интерфейсом, скрывающим их реализацию. В рамках дискурса общих информационных технологий безусловно делается предположение, что человеку, мыслящему на определённом уровне абстракции, нет нужды вникать в специфику реализации задействованных на данном уровне блоков, иначе нарушается принцип чёрного ящика. Это предположение не является безусловно корректным если речь идёт о критических системах, где необходима высокая живучесть/отказоустойчивость. Объясняется это тем, что второстепенные функциональные особенности различных компонентов в совокупности могут порождать потенциально опасные непредусмотренные поведения (как это демонстрируют былинные отказы Mars Climate Orbiter, Airbus A400M в Севилье, Ariane 5, и т.п.).

Растущая сложность бортового оборудования отражается в развитии стандартов безопасности. Более сложные системы создаются композицией более сложных подсистем, что формирует спрос на конкретные гарантии поведенческих характеристик компонентов (если у нас есть, скажем, радар, мы хотим точно знать, в каких условиях и как он будет работать, как его характеристики коррелируют с параметрами среды, и вообще неплохо бы убедиться, что его разработчики мышей ловят). Примером ответа индустрии на этот запрос будет концепция Safety Element out of Context (SEooC), введённая в новом автомобильном стандарте ISO 26262. Строго говоря, тема стандартизации не имеет прямого отношения к нашему сугубо техническому проекту, но она отражает общие тренды в индустрии к переходу к композициям более сложных компонентов и как следствие, более сложных интерфейсов.

Холистический анализ сложных систем невозможен по очевидным причинам; фрагментарные же подходы в области высокой надёжности усложняются необходимостью детальной формализации и верификации поведений функциональных блоков с целью минимизации рисков возникновения непредусмотренных поведений при их интеграции. В этом свете выглядит целесообразным поиск методов построения чёрных ящиков, который предоставлял бы удобные инструменты создания абстрактных интерфейсов, и в то же время привносил бы минимальные накладные расходы на формализацию/верификацию блоков и их композиций.

Здесь следует внести разъяснения касательно специфики реального времени и высокой надёжности для читателя, не являющегося специалистом в этой области. Разработчик прикладного ПО, веб-сервера или типичной бытовой встраиваемой системы (вроде компьютерной периферии) сочтёт покрытие тестами достаточной гарантией адекватности ПО. Проблемы реального времени в сложных системах такого рода возникают редко, а когда они возникают, цена временных отклонений обычно достаточно мала, чтобы можно было пренебречь жёстким ресурсным планированием или формальным анализом планировки задач (schedulability analysis). Процессы жёсткого реального времени обычно либо просты, либо цена ошибки несущественна (в качестве примера бытового жёсткого реального времени можно принять логику работы печатающей головки струйного принтера, привод экструдера 3D печати или аудиокодек). Эмпирические методы в целом преобладают над формальными; повсеместно применяется бенчмаркинг и амортизационный анализ. Если продукт показывает приемлемые результаты в подавляющем числе случаев, он принимается соответствующим требованиям; более строгие подходы обычно нецелесообразны финансово.

Разработчик критических систем транспортного средства имеет дело с иным балансом стоимости создания ПО и потенциального ущерба от последствий его сбоев (это верно даже в случае средств микромобильности и малых БПЛА). Большинство таких систем работают в реальном времени, где несвоевременное исполнение задачи эквивалентно неисполнению. Изменение баланса стоимости оправдывает увеличение вложений в средства обеспечения функциональной безопасности с целью снижения эксплуатационных рисков. Как следствие, доказательные методы, верификация и валидация, широко распространены.

Говоря о балансе проектировочных затрат и рисков, интересная тенденция сейчас имеет место в космической отрасли: как метко отмечает Casey Handmer, наблюдаемое ныне снижение стоимости вывода космических аппаратов (КА) сдвигает оптимальный баланс в сторону решений с менее строгими гарантиями безопасности и менее затратной разработкой. В случае же БПЛА наблюдается обратный тренд ввиду распространения более ответственных применений и увеличения числа аппаратов в эксплуатации.

Различные исходные предпосылки при создании систем разного уровня функциональной безопасности проявляются в, порою, радикально различных технических свойствах их компонентов и предпочитаемых методах их создания. Скажем, бортовая коммутируемая сеть современного авиалайнера (как AFDX) предоставляет гарантированные минимальные кривые обслуживания, и, как следствие, для хорошо спланированного трафика отсутствует потребность в подтверждении доставки. Для типичной коммерческой системы эта логика чужда, ведь свойства сети и её загрузку никто не гарантирует. Асимптотический анализ в рамках жёсткого реального времени сфокусирован на худшем случае нежели амортизированном случае, что порою может радикально менять подходы на всех уровнях проектирования.

Различия в предпосылках также объясняют, почему прекрасно зарекомендовавшие себя в ИКТ решения (тысячи их: очереди сообщений, фреймворки, сетевые стеки с TCP/IP во главе, распределённые БД, операционные системы, etc.) обычно непригодны для ответственных применений и почему безопасные системы часто отдают предпочтение специализированным технологиям.

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

Обычный порошок

Картина положения дел в индустрии будет неполной без хотя бы поверхностного рассмотрения существующих технологий построения отказоустойчивых распределённых систем реального времени. Решения эти обычно интересны технически, созданы с оглядкой на многолетний опыт и проверены временем в реальных продуктах. Однако, тем не менее, горшки CiA/SAE/RTCA/EUROCAE/AUTOSAR/OMG/etc. обжигают отнюдь не боги.

Технологии мы поделим на категории по уровню абстракции коммуницируемых состояний и потенциала к созданию сложных систем. Эта модель игнорирует тонкости и в граничных случаях может быть некорректна, но она справляется с главной задачей: объяснением общего положения дел и демонстрацией рассогласования между запросами индустрии и доступными решениями. Пойдём от простого к сложному.

1. Аналоговые схемы

Просто и прямолинейно. Электрические, пневматические, гидравлические, механические средства непосредственного взаимодействия между узлами и компонентами попадают в эту категорию. Приведённая ранее схема ВАЗ 21099 тоже отсюда.

Базовым примитивом межкомпонентного взаимодействия здесь будет аналоговый или дискретный сигнал представленный напряжением/током в электрической цепи, давлением в линии, натяжением троса, и т.п.

2. Логическая шина

Шина данных есть довольно общий термин. Мы здесь под этим подразумеваем модель взаимодействия, где атомарной единицей данных является структура из логически связанных сигналов/параметров, и внимание проектировщика в значительной мере сосредоточено на определении этих структур и логики их обмена.

Следует разделять топологию физическую и логическую: методы соединения узлов и пересылки пакетов не имеют отношения к потокам данных на уровне приложения. На физическом уровне мы выделяем три ключевые топологии: точка-(много)точка, физическая шина и коммутируемая сеть, любая из которых может использоваться для построения логической шины.

Начнём с первого. Если компонент А непрерывно сообщает компоненту Б больше одного параметра, имеет смысл временное разделение (мультиплексирование) сигналов. Такое уплотнение позволяет наращивать число параметров при постоянном числе физических межкомпонентных соединений, что удешевляет/облегчает конструкцию. Практическим примером будет ARINC 429 древний и незамысловатый авиационный протокол, реализующий обмен фиксированными 18-битными словами с щепоткой метаданных по выделенным (некоммутируемым) линиям. Типичная топология выглядит так:

Диаграмма адаптирована из "The Evolution of Avionics Networks From ARINC 429 to AFDX", Fuchs, 2012.

ARINC 429 довольно атипичен как бортовая шина тяжело привести другой пример использования физической топологии точка-многоточка (хотя причастные к малым дронам могли бы вспомнить здесь DShot и MAVLink; последний изначально предназначен для беспроводной связи с наземной станцией, но иногда применяется для внутрибортовой коммуникации). Этот подход имеет особый смысл в простых критических системах жёсткого реального времени, потому что временные свойства процесса доставки сигнала от отправителя к получателю абсолютно очевидны и не требуют сложного анализа. Среда передачи не разделяется с другими компонентами, поэтому нет нужды оценивать вклад каждого в загрузку среды и результирующие побочные эффекты. Однако, этот метод не масштабируется и делает логику взаимодействия сильно зависимой от физических параметров сети (если к компоненту не потрудились пробросить кабель при проектировании, соответствующих данных он никогда не получит).

Широкое распространение получила шинная топология (мы говорим о физическом уровне, не забывайте). Вероятно, CAN не нуждается в представлении; на нём основано множество протоколов и стандартов верхнего уровня. Здесь же FlexRAY, LIN, MIL-STD-1553 и ранние стандарты Ethernet (современный Ethernet используется только в коммутируемой конфигурации).

CAN показателен в контексте реакции отрасли на рост сложности продукции. Введённая в 1986 первая версия стандарта предлагала крайне ограниченный MTU в 8 байт на пакет. В 2012 появился CAN FD с MTU в целых 64 байта и увеличенной пропускной способностью. С конца 2018 года в активной разработке находится CAN XL с MTU 2 КиБ и ещё чуть более высокой скоростью (начало ISO стандартизации запланировано на 2021 год).

Говоря о физических шинах, нельзя не вспомнить интереснейшее начинание под названием Wireless Avionics Intra-Communications (WAIC). WAIC предлагает повысить отказоустойчивость бортовых критических сетей введением гетерогенной избыточности, где резервным каналом станет беспроводной. В целом, беспроводные бортовые сети можно считать фундаментально менее надёжными, чем бортовые проводные/оптические, ввиду слабого контроля за состоянием среды обмена (эфир один на всех). Однако, в совокупности с традиционными сетями, беспроводные позволяют поднять отказоустойчивость из-за устранения отказов общего вида, свойственных проводным сетям, ведь механическое повреждение элемента конструкции может с высокой вероятностью повредить все избыточные проводные соединения:

Диаграмма с сайта WAIC.

Физическая шина размещает всех участников на едином сегменте сети, что создаёт проблемы масштабируемости, ведь все узлы вынуждены организовывать обмен внтутри общего домена коллизий. Сложные транспортные средства на острие прогресса (скажем, современные авиалайнеры и космические аппараты) не в состоянии организовать работу систем в пределах ограничений существующих физических шин, поэтому в ход идут коммутируемые сети. Из значимых следует вспомнить SpaceWire (чрезвычайно узкоспециализированная технология; насколько мне известно, совершенно не представлена вне КА) и, конечно, Ethernet.

В современном аэрокосмосе широко применяется коммутируемый Avionics Full-Duplex Switched Ethernet (AFDX) как на стомегабитной медной паре, так и на оптике (см. Boeing 787). Несмотря на передовой физический уровень, логически это всё тот же ARINC 429, где физические соединения точка-точка заменены их виртуальными репрезентациями. Это решает проблемы масштабируемости, но не предоставляет новых инструментов проектирования логики. Сети AFDX проектируются со статическим планированием обмена с применением автоматических доказательств, что позволяет получить гарантированные временные характеристики доставки несмотря на привнесённые коммутацией сложности. Широко применяется полное дублирование сетевого аппаратного обеспечения (коммутаторов и кабельной системы) для отказоустойчивости. Ниже показан пример физической топологии AFDX подсети космического аппарата с дублированием; при этом логическая сеть ARINC 429, построенная поверх (не показана), определяется конфигурацией ПО коммутаторов вместо физической конфигурации кабельной системы:

Диаграмма из "Communications for Integrated Modular Avionics", Alena, 2007.

Гарантированные параметры сети объясняют почему в сетях жёсткого реального времени редко применяется подтверждение доставки. Вторая причина в том, что процессы реального времени часто предполагают сторого периодический обмен данными, где затраты времени и ресурсов сети (которые, замечу, под строгим учётом) на отправку подтверждения или второй копии данных оказываются неоправданными из-за скорой отправки очередного пакета с более новыми данными в рамках естественного течения процесса. Поэтому, в частности, AFDX построен на (слегка модифицированном) протоколе UDP/IPv4. Использование классических "надёжных" протоколов вроде TCP/IP в подобной среде было бы не просто излишним, а контрпродуктивным они несовместимы с особенностями процессов реального времени.

Общая характеристика рассмотренных технологий и построенных на их основе высокоуровневых протоколов заключается в их ориентированности на организацию низкоуровневых сценариев взаимодействия, где фокус внимания проектировщика сосредоточен на группах определённых параметров и их пересылке между конкретными аппаратными и программными компонентами. На логическом уровне мы всё так же имеем дело со жгутами виртуальных проводов, как на схеме ВАЗ 21099. Подобно тому, как рост сложности решений заставил индустрию ИКТ пережить несколько смен парадигмы за последние десятилетия, подходы к построению архитектуры распределённых бортовых систем претерпевают изменения под давлением спроса на автономность и автоматизацию транспортных средств. В 2020 мы наблюдаем первые симптомы несостоятельности традиционных методов и попытки к переходу на качественно более мощные средства, о чём будет следующий раздел.

3. Распределённые вычисления

Рассматриваемые здесь распределённые системы создаются из множества компонентов, которые реализуют сложные поведения и манипулируют большим числом внутренних состояний. Принцип чёрного ящика, чьё применение необходимо в силу когнитивных ограничений человека-проектировщика, предписывает сокрытие конкретики внутренних состояний и процессов за абстрактными межкомпонентными интерфейсами. Возникающая потребность в нетривиальной трансляции и интерпретации между моделью интерфейса и внтуренними состояниями является фундаментальным отличием концепции распределённых вычислений от логической шины.

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

Пожалуй, наиболее значимым на сегодня примером такого подхода будет граф распределённых вычислений из Robot Operating System (ROS) (строго говоря, ROS не является операционной системой, это скорее высокоуровневый фреймворк). Изначально ROS был создан в качестве SDK для окологуманоидного робота PR2 от Willow Garage, но исследователи быстро увидели потенциал фреймворка в других робототехнических системах (от пылесосов и манипуляторов до БПЛА и робоавтомобилей), и он превратился в самостоятельный проект. За несколько лет вокруг ROS развилась богатая экосистема программного обеспечения, решающего многие типовые задачи вроде компьютерного зрения, локализации и картографирования, взаимодействия с аппаратным обеспечением, и т.п. Если изначально фреймворк создавался для исследовательских задач, то интенсивное развитие его экосистемы (и отрасли в целом) со временем поставило вопрос о продуктизации и трансфере наработок из лабораторий в полевые условия, с чем возникли значительные трудности.

Пример визуализации распределённых процессов на ROS. На схеме показан фрагмент системы управления автономного БПЛА в режиме программно-аппаратного моделирования. Овалы обозначают процессы, прямоугольники и стрелки обозначают связи издатель-подписчик.

Описание полного спектра проблем продуктизации основанных на ROS изделий приведёно в статье Why ROS 2 [Gerkey], которая, как нетрудно догадаться из названия, решительно предлагает выпустить вторую версию с оглядкой на новые потребности индустрии. Одной из ключевых проблем здесь является неспособность изначально исследовательского фреймворка удовлетворить радикально более жёсткие требования продуктовых систем к предсказуемости и гарантиям безопасности, которые зачастую обусловлены не только коммерческим интересом, но и законодательным регулированием (особенно в случае автомобильной или аэрокосмической отрасли). Коммуникационная подсистема ROS, обеспечивающая межкомпонентные взаимодействия, является одной из наиболее критических и сложных частей фреймворка. В первой версии использовалась собственная реализация, созданная с нуля, принципиально несовместимая с ответственными применениями, из-за чего во второй версии в роли коммуникационной подсистемы использовали популярное готовое решение Data Distribution Services (DDS).

DDS является сильно отдалённым потомком CORBA, ориентированным на реальное время и модель издатель-подписчик (с недавних пор предлагается также встроенная поддержка клиент-серверных взаимодействий, но на практике первый тип наиболее востребован). DDS широко применяется не только в транспорте и робототехнике, но и в промышленности вообще, зачастую выступая в роли выделенного коммуникационного слоя (собственно, как в случае ROS 2) для вышележащих технологий. Особого упоминания здесь заслуживает Future Airborne Capability Environment (DDS FACE) для критической авионики; однако, на сегодняшний день, большая часть реальных применений DDS в аэрокосмосе приходится на немногочисленные военные системы, которые не следуют гражданским стандартам безопасности.

Как было упомянуто, DDS дальними корнями уходит в CORBA оба стандарта поддерживаются одной организацией. Последняя изначально не предназначалась для систем реального времени, но отраслевые реалии заставили исследователей начать рассматривать вопросы её адаптации для реального времени ещё в конце прошлого века. В работе "The Design of the TAO Real-Time Object Request Broker" [Schmidt et al, 1999] большое внимание уделяется тому факту, что проектирование адекватной сети реального времени самой сетью не ограничивается обязательному анализу подлежат вопросы реализации логики протокола на конечных узлах с соблюдением временных гарантий. В разрезе CORBA синопсис рассматриваемых проблем приведён ниже; эти же принципы легко переносятся на практически любую современную технологию того же толка:

Цифрами обозначены ключевые аспекты реализации, где предписан анализ временных характеристик внутренних алгоритмов протокола. Диаграмма из "The Design of the TAO Real-Time Object Request Broker", Schmidt et al, 1999.

Шмидт с коллегами воплотил идеи в популярной ныне C++ библиотеке TAO (The ACE ORB), которая легла в основу некоторых современных реализаций DDS. Сама по себе TAO насчитывает более двухсот тысяч строк кода без учёта специфики DDS, которая привносит ещё дополнительный код сверху. Из более современных и независимых от TAO инкарнаций DDS упомяну, пожалуй, наиболее многообещающую на сегодня eProsima Fast-DDS (это оценочное суждение, а не реклама) без сторонних зависимостей и тестов она занимает более трёхсот тысяч строк C++ кода (и реализует при этом не все опциональные возможности стандарта). Эти сведения приведены с целью иллюстрации порядка концептуальной сложности DDS.

Как нетрудно догадаться из вышеизложенного, DDS также отличается высокими требованиями к вычислительной платформе, что помимо прочего ограничивает использование во встраиваемых системах. Конкретно эта проблема отчасти решается специализированным подмножеством DDS For Extremely Resource Constrained Environments (DDS-XRCE). Но, согласно нашей модели, это решение уже выходит далеко за пределы концепции распределённых вычислений в силу своей глубокой зависимости от центрального координирующего агента и ограниченной функциональности. Для рассматриваемого здесь вопроса эта технология большой ценности не представляет и рассматривать мы её не будем, равно как мы обойдём стороной и связанный проект micro-ROS.

Из других решений есть смысл поверхностно упомянуть SOME/IP часть автомобильного стандарта AUTOSAR v4+, предлагающую сервисы построения распределённых систем поверх стека IP. В отличие от DDS, SOME/IP сфокусирован исключительно на автомобильных применениях и оперирует существенно более низкоуровневыми концепциями со слабой сегрегацией по уровням абстракции. В совокупности с довольно вольготным обращением с распределёнными состояниями (об этом поговорим далее) и значительным логическим зацеплением между коллабораторами это вызывает вопросы о будущем SOME/IP при наличии сильного конкурента в лице DDS.

Распространённые в ИКТ альтернативы вроде MQTT и разнообразных специализированных фреймворков не учитывают аспекты реального времени и гарантий поведенческих характеристик, поэтому в наших приложениях встретить их можно редко и рассматривать их здесь не имеет смысла.

Высокая внутренняя сложность существующих технологий распределённых вычислений обусловлена широким спектром поддерживаемых сценариев и типов взаимодействия, лишь малая часть которых актуальна для интересующей нас области применений. Мы полагаем, что это утверждение верно даже для специализированных решений (как SOME/IP), чья архитектура может подлежать улучшениям путём целостного пересмотра подходов к проектированию бортовых распределённых систем. Аккуратное переосмысление основных требований к коммуникационной подсистеме позволило нам достичь более взвешенного баланса между внутренней сложностью (и, как следствие, стоимостью валидации и верификации и обеспечения гарантированных характеристик) и доступными инструментами построения мощных абстракций.

Наш подход

Мы едим нашу собаку уже не первый год, и только сейчас подобрались к выпуску первой долгосрочно стабильной версии стандарта, которую мы называем UAVCAN v1. Этому эпохальному для нас событию предшествовали исследования и экспериментальные развёртывания в реальных системах, на протяжении которых менялись наши методы, но не менялись ключевые цели:

1. Простота понимания и реализации. Как было показано выше, это исключительно важно для критических систем. Протокол масштабируется согласно сложности использующего его компонента распределённой системы (т.е., аппаратного узла или программы): в простых компонентах совместимая реализация протокола должна умещаться в одну тысячу строк; в очень сложных она может расти до пары десятков тысяч строк.

   
   

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

   
   

3. Отказоустойчивость. Протокол реализует одноранговую децентрализованную сеть со встроенной поддержкой избыточности. Обеспечивается совместимость с ненадёжными сетями реального времени, где возможны потери пакетов в результате деструктивных воздействий среды (например, электромагнитная интерференция), но не самой сети (например, переполняющийся буфер).

   
   

4. Предсказуемость. Протокол изначально спроектирован для задач реального времени и для использования во встраиваемых системах от младших однокристалок без ОС с единицами КиБ памяти до мощных компьютеров под управлением сложных ОС, причём не обязательно реального времени. Поддерживаются средства высокоточной синхронизации времени в пределах сети для нужд распределённых контуров управления. Ресурсный потолок всегда тривиально предсказуем и доказуем.

   
   

5. Открытость. Это не техническое требование, а юридическое, но это не делает его менее значимым. Невозможно обеспечить серьёзные внедрения закрытой технологии, если существенная часть отрасли живёт открытыми стандартами и открытым ПО. Этот пункт подразумевает свободное распространение всей документации и кода под разрешительными лиценизиями (CC BY, MIT) без обязательных членских взносов.

   
   

В части погони за простотой как одной из ключевых характеристик можно усмотреть реминисценции известного в определённых кругах алгоритма распределённого консенсуса Raft, чьи создатели точно так же, как и мы, начали с вопроса о том, как сделать сложные вещи простыми. Хотя область их деятельности не имеет ничего общего с нашей, они, как и мы, в конечном итоге решали проблему восприятия, где единственной гарантированно достоверной метрикой является человеческий опыт. В отличие от авторов Raft, мы не проверяли трудность понимания наших спецификаций на больших массах людей (N.B.: они показали видео-лекцию 43-м студентам и потом оценили понимание при помощи теста, сравнив результаты с конкурирующей технологией). Однако, у нас есть вот такое практическое свидетельство, где господин зашёл с улицы и сделал минимальную реализацию UAVCAN с нуля за "пару недель" (с его слов):

Желающие увидеть код найдут его на гитхабе как libuavesp. Я, обратите внимание, умываю руки мы к этой реализации отношения не имеем. Заявление автора о том, что "UAV" в названии "UAVCAN" имеет отношение к БПЛА, не соответствует действительности и вызвано банальным недоразумением.

Как нетрудно догадаться из предваряющей этот раздел вводной, UAVCAN широко заимствует ценные принципы из флагманов современной индустрии, в первую очередь опираясь на ROS, DDS, AFDX, WAIC и множество высокоуровневых CAN протоколов, которые даже нет смысла здесь перечислять. Однако, вопросы организации распределённых вычислений одними транспортными протоколами, очевидно, не ограничиваются, особенно если учесть заявленную в ключевых целях потребность в "высокоуровневых абстракциях". UAVCAN удобно рассматривать в виде трёхуровневой модели (мы намеренно игнорируем семиуровневую модель OSI ввиду её чрезмерной детализации):

• Уровень приложения. На этом уровне представлены общие для всех бортовых систем функции: мониторинг состояния, логирование, передача файлов, управление конфигурацией, телеметрия, и т.п. На этом же уровне создаются специализированные сервисы согласно потребностям конкретного приложения. В распоряжении пользователя два вида взаимодействий: анонимный статически типизированный издатель-подписчик и статически же типизированный удалённый вызов процедур с явной адресацией (т.е. не анонимный).

  
  

• Уровень представления отвечает за маршалинг доменных объектов в связях издатель-подписчик и при удалённом вызове процедур. Этот уровень реализован средствами специального предметно-ориентированного языка, на котором даётся строгое определение типов данных для сетевого обмена: Data Structure Description Language (DSDL). На основе DSDL-дефиниций можно автоматически генерировать код (можно и не автоматически).

  
  

• Транспортный уровень занимается доставкой объектов согласно связям издатель-подписчик и удалённым вызовам процедур. Этот уровень намеренно сильно изолирован от вышележащих двух, что позволяет нам определить несколько транспортов поверх различных нижележащих протоколов:

  
  
  • UAVCAN/CAN работает поверх классического CAN и CAN FD. Вероятно, в будущем также появится поддержка CAN XL, но это не точно.
  • UAVCAN/UDP работает поверх UDP/IP. По состоянию на 2020-й год, спецификация этого транспорта ещё находится в стадии ранней альфы и может быть изменена до стабилизации (хотя предпосылок к этому нет).
  • UAVCAN/serial работает поверх любого байт-ориентированного протокола (UART, RS-232/422/485, USB CDC ACM) и ещё подходит для хранения дампов в неструктурированных бинарных файлах. Этот транспорт тоже ожидает стабилизации.
  • Поскольку интерфейс между транспортом и верхними уровнями хорошо определён, в будущем возможно добавление новых транспортных протоколов. В числе таковых рассматривается, например, беспроводной IEEE 802.15.4.
  
  

У нас есть несколько безусловных исходных предположений, которые довольно однозначно очерчивают область применимости протокола. Строгий фокус на бортовых сетях реального времени означает, что попытки использования UAVCAN в любых других областях скорее всего приведут к посредственным результатам, что мы, однако, не расцениваем как недостаток.

Первое из исходных предположений таково: нижележащая транспортная сеть (например, CAN или Ethernet, в зависимости от выбранного транспорта) предлагает хорошо охарактеризованную минимальную кривую обслуживания и нулевую вероятность потерь пакетов при отсутствии неблагоприятных воздействий внешней среды. Последнее означает, что потери не могут возникнуть в результате процессов, протекающих внутри сети, как, например, переполнение буфера на сетевом узле; однако, допускаются кратковременные нарушения, вызванные внешними факторами, как, например, электромагнитная интерференция. Это предположение полностью совместимо с реалиями настоящих бортовых систем, и оно позволяет нам существенно упростить логику протокола. Компенсация потерь ввиду внешних воздействий выполняется путём превентивной отправки дубликатов (только в тех случаях, где требуется). Рассмотрение этого метода даётся в статье Idempotent interfaces and deterministic data loss mitigation. Хотя описанные особенности выглядят чуждыми для традиционных систем, они вполне оправданы для нашей области.

Крайне аккуратное обращение с разделяемым состоянием позволяет нам сильно сократить пространство состояний сетевых узлов в сравнении со схожими решениями. В результате сокращается техническая сложность реализации, упрощается её анализ и тестирование, о чём подробно сказано в официальном руководстве. Сетевой узел UAVCAN делает минимум предположений о состоянии своих коллабораторов; например, если в случае традиционного фреймворка издатель-подписчик обычно выделяется явная процедура установления подписки, где подписчик сообщает издателю о своей заинтересованности в конкретных данных (см. SOME/IP, DDS, ROS, практически все MQ*, etc.), в UAVCAN издатель слепо отправляет данные в сеть, позволяя заинтересованным агентам их принять или проигнорировать.

Последнее обстоятельство создало бы существенные преграды для масштабирования, если бы не широкое использование аппаратной фильтрации пакетов в обязательном порядке. Известные нам другие протоколы (кроме AFDX) необоснованно игнорируют тот факт, что всё современное аппаратное обеспечение для высокоскоростной коммуникации, за исключением лишь некоторых маргинальных представителей, предоставляет мощные аппаратные инструменты автоматической фильтрации. Разумная эксплуатация этого факта позволила нам ввести радикальные упрощения без ущерба функциональности, о чём говорится в статье Alternative transport protocols in UAVCAN.

Очередное исходное предположение заключается в том, что сеть и её участники имеют, в целом, статическую природу. Это следует трактовать трояко. Во-первых, конфигурация бортовых систем редко подлежит радикальным изменениям в полевых условиях, что позволяет нам сэкономить на сложности динамической автоконфигурации в большинстве случаев; это, впрочем, не означает, что полевая реконфигурация невозможна в принципе (она полезна в исследовательских и экспериментальных окружениях), но это означает, что средства реконфигурации вынесены в опциональные части протокола, которые могут быть удалены в интересах упрощения валидации и верификации сертифицируемых отказоустойчивых систем.

Например, динамическое выделение адреса в сети поддерживается опциональным механизмом plug-and-play (впрочем, конкретно для UAVCAN/UDP он не определён ввиду наличия стандартного DHCP). Механизм этот также поддерживает избыточные аллокаторы для отказоустойчивых систем, где консенсус реплик обеспечивается при помощи упомянутого ранее алгоритма Raft.

Второй аспект статичности заключается в предоставлении ресурсного потолка для любой части системы на этапе проектирования. Так, определяемые при помощи упомянутого ранее DSDL типы всегда имеют верхний предел размера любого поля переменной длины, из чего следует, что максимальное время передачи, максимальное время сериализации/десериализации, и, в общем случае, максимальное время обработки всегда можно определить статически. Ниже показано DSDL-определение стандартного типа журнальной записи под именем uavcan.diagnostic.Record, где можно видеть, что максимальная длина сообщения задана явно и ограничена 112-ю байтами (кодировка всегда UTF-8):

# Generic human-readable text message for logging and displaying purposes.# Generally, it should be published at the lowest priority level.uavcan.time.SynchronizedTimestamp.1.0 timestamp# Optional timestamp in the network-synchronized time system; zero if undefined.# The timestamp value conveys the exact moment when the reported event took place.Severity.1.0 severityuint8[<=112] text# Message text.# Normally, messages should be kept as short as possible, especially those of high severity.@assert _offset_ % 8 == {0}@assert _offset_.max <= (124 * 8)     # Two CAN FD frames max

В конце определения видно вспомогательные конструкции, добавленные с целью статической проверки способности двух CAN FD фреймов нести сообщение максимального размера.

В предшествующей секции было отмечено, что протокол реального времени должен проектироваться с учётом доступных средств реализации с соблюдением временных характеристик. Если представление данных в гарантированное время в целом делается возможным благодаря свойствам DSDL, своевременность их обработки на нижних уровнях протокола (на транспортном, то есть) достигается благодаря явно определённому потолку для всех ресурсов протокола. Например, максимальное количество каналов издатель-подписчик в системе ограничено (этот максимум, однако, очень высок десятка тысяч каналов достаточно каждому), равно как и максимальное количество узлов в сети. В спецификации рассматриваются практические подходы к реализации транспортной логики (а именно, демультиплексирования пакетов и реконструкции полезной нагрузки из мультикадровых передач) с оценкой влияния различных методов на асимптотическую сложность.

Третий аспект статичности следует из нашего крайне осторожного обращения с распределённым состоянием (однажды я сделаю себе татуировку на лицо с предупреждением о том, что все болезни идут от взаимодействий с чрезмерным сохранением состояния). Отсутствие явно синхронизируемых состояний между коллабораторами (между издателем и подписчиком или между клиентом и сервером в случае удалённого вызова процедур) позволяет вновь подключенному участнику приступить к выполнению своих задач немедленно, без предварительных процедур регистрации, обнаружения служб, и т.п. Это имеет значение при анализе сценариев отказа, где критическое устройство кратковременно отключается (например, в результате непреднамеренного перезапуска) с последущим повторным присоединением к сети.

Для примера я продемонстрирую сериализацию и публикацию сообщения, определённого ниже, содержащего три константы и два поля. Константы не участвуют в обмене, поскольку они и так известны всем узлам, имеющим доступ к соответствующему определению типа. Поля сериализуются в плоский остроконечный бинарный формат (младший байт идёт первым) примерно как в ASN.1 UPER (другой порядок байт), но с местной спецификой (ценители сериализации данных должны посмотреть мою заметку, где я рассматриваю популярные форматы и сравниваю их с DSDL).

uint16 VALUE_LOW  = 1000uint16 VALUE_HIGH = 2000uint16 VALUE_MID = (VALUE_HIGH + VALUE_LOW) / 2# Рациональная арифметика произвольной точности!uint16 valueuint8[<=100] key  # Динамический массив от 0 до 100 элементов.

Если мы, скажем, присвоим полям значения value=1234 и key=Hello world!, результат в шестнадцатиричной нотации будет следующим:

D2 04 0C 48 65 6C 6C 6F 20 77 6F 72 6C 64 21

Где D2 04 соответствует 1234, 0C длина массива (если бы максимальная длина была более 255 элементов, тут было бы два или четыре байта), и остаток приходится на приветствие.

Публикация сообщения через классический CAN будет выглядеть предельно незамысловато все счастливые CAN протоколы похожи друг на друга (надо ли говорить, что в случае CAN FD всё вошло бы в один кадр):

$ candump -decaxta any(7.925)  vcan2  TX - -  1013373B   [8]  D2 04 0C 48 65 6C 6C A0   '...Hell.'(7.925)  vcan2  TX - -  1013373B   [8]  6F 20 77 6F 72 6C 64 00   'o world.'(7.925)  vcan2  TX - -  1013373B   [4]  21 F9 02 60               '!..`'

Лишний подозрительный байт в конце каждого кадра содержит метаданные транспорта. В конце последнего кадра есть два байта циклического избыточного кода для проверки корректности декадрирования.

Колонка со значением 0x1013373B здесь представляет CAN ID, что является битовой маской из нескольких полей с метаданными. Наиболее интересным здесь является значение 0x1337 (4919 в десятичной системе), которое называется идентификатором темы (subject-identifier) в отличие от некоторых более сложных протоколов (как DDS), UAVCAN не поддерживает именованные топики, предлагая вместо них нумерованные темы (похоже на SOME/IP и практически любой протокол поверх CAN). Это значение проектировщик выбирает произвольно, сообразно своим представлениям о системе.

Теперь мы можем повторить упражнение для UAVCAN/UDP на localhost. Wireshark, к сожалению, пока не имеет диссектора для UAVCAN, да и пёс с ним, ведь и так всё ясно:

Дотошный читатель спросит, откуда взялся порт назначения 21303, на что я отвечу, что он вычисляется как сумма идентификатора темы (4919 у нас) и фиксированного смещения 16384. Смещение выбрано таким образом, чтобы сдвинуть порты UAVCAN в эфемерный диапазон с целью минимизации конфликтов. Исходный порт полезной информации не несёт и выбирается произвольно. Нашу полезную нагрузку (D2 04 0C ...) предваряют 24 байта метаданных, добавленных стеком UAVCAN; там содержится информация о приоритете, фрагментах (тут их нет) и последовательном номере сообщения.

Будет ошибкой думать, что внедрение UAVCAN/UDP в обязательном порядке требует полного IP стека. Когда на практике поднимается вопрос об IP стеке, обычно подразумевается TCP/IP, сложность которого несопоставима с UDP/IP. Последний можно собрать с нуля на C в несколько сотен строк, как наглядно продемонстрировал Lifelover в 2011-м году в серии публикаций "Подключение микроконтроллера к локальной сети".

Здесь практические упражнения мы заканчиваем, потому что публикация не об этом. Желающим закатать рукава следует пройти в библиотеку с говорящим названием PyUAVCAN, при помощи которой эти примеры были получены (не будет лишним также заглянуть в руководство).

Нельзя обойти вниманием встроенную поддержку как гомогенной, так и гетерогенной избыточности транспорта. Первый тип достаточно часто встречается на практике, но особенно интересен последний в предыдущей секции я отметил потенциал разнородной избыточности к увеличению отказоустойчивости сети благодаря устранению отказов общего вида. На транспортном уровне встроена логика дедупликации и автоматического переключения между избыточными сетевыми интерфейсами прозрачно для приложения. С практической стороной реализации можно также ознакомиться в документации к PyUAVCAN.

Последним заслуживает рассмотрения уровень приложения. Техническая сторона вопроса прозрачна: пользователь определяет собственные типы с использованием DSDL, затем создаёт соответствующие темы (топики) по мере надобности. Для распространённых задач (мониторинг узлов, файлообмен, логирование, управление конфигурацией, и т.п.) нет нужды конструировать собственные сетевые сервисы, потому что соответствующие определения предоставляются стандартным набором сервисов UAVCAN, из которого можно свободно выбрать необходимые.

Поверх UAVCAN предполагается создание специализированных отраслевых стандартов уровня приложения, примерно как стандартные классы USB существуют поверх ядра USB, как профили CANopen или Bluetooth, или как DDS FACE поверх DDS. Схематически мы это изображаем следующим образом:

Из отраслевых стандартов сейчас в работе один так называемый Drone Standard 15, или DS-015, к которому активно прикладывают руки, среди прочих, компании из Dronecode Foundation. Мы предвидим появление других отраслевых спецификаций в будущем, поскольку UAVCAN сегодня можно встретить далеко за пределами одних только дронов но об этом позже.

Техническая сторона здесь прозрачна, но есть и другая. Сложные распределённые системы требуют дисциплинированного подхода к проектированию сетевых сервисов и их интерфейсов. Контакты с сообществом разработчиков встраиваемых систем показали, что эта аудитория может глубоко разбираться в вопросах, традиционно характерных для их области деятельности (реальное время, операционные системы, связующее ПО, и т.п.), но при этом иметь очень ограниченное представление о проектировании адекватных сетевых сервисов. Накопленный опыт работы с несколько более низкоуровневыми технологиями, по-видимому, подталкивает людей к неуместному заимствованию практик, что неоднократно на нашем опыте приводило к появлению дефектных интерфейсов, работа с которыми наполовину состоит из страдания. Решение этой нетехнической проблемы является столь же нетехническим мы опубликовали учебный материал, где подробно объясняется, как выглядит сетевой сервис здорового человека. Материал этот опубликован в официальном руководстве UAVCAN в главе Interface Design Guidelines.

Внедрение

Прогресс в области вычислительной техники, элементов питания, машинного обучения, генеративного проектирования и других передовых областей порождает новые проекты транспортных систем, которые зачастую реализуются малыми предприятиями при минимальном финансировании и низкой стартовой вовлечённостью в релевантные отрасли. Практические примеры автономных дронов и роботов, электрических конвертопланов, кубсатов, робоавтомобилей, и т.п. в изобилии присутствуют в новостных лентах, так что приводить их здесь нет смысла. Каждое такое средство, будучи передовым продуктом 21-го века, критически зависимо от грамотной огранизации бортовых вычислительных систем, и часто также несёт груз правового регулирования и доказательства функциональной безопасности. Такие проекты неспособны подняться без широкого применения именно открытых стандартов и свободных решений, потому что как коммерческие альтернативы, так и доморощенные велосипеды рискуют не вписаться в бюджет. Стартап, скажем, с летательным аппаратом, намеревающийся следовать стандартам консервативной аэрокосмической отрасли на первом же шаге выложит десятки тысяч евро за PDF документы; в то же время будет ошибкой думать, что внедрение этих стандартов является необходимым или даже желательным условием для успеха.

UAVCAN полностью открыт для распространения и внедрения, не предписывает никаких лицензионных ограничений: вся документация распространяется под CC BY 4.0, а исходный код референсных реализаций под MIT. Вероятно, любой другой подход к лицензированию сегодня обрёк бы проект на забвение.

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

Согласно принципам открытости, вся разработка ведётся в полностью публичной манере на форуме и на GitHub оба этих ресурса вместе содержат не меньше 90% дискуссий разработчиков по существу, так что любое просочившееся в спецификацию решение оставляет перманентный бумажный след. Этот подход радикально отличается от традиционных практик, где обычно предполагается платное членство и участие в закрытых сессиях, закрытых ревью стандартов и закрытых же списках рассылок.

На гитхабе поддерживаются референсные библиотеки, среди которых Libcanard минимальная реализация UAVCAN/CAN для однокристалок на C11, объём кода которой фигурирует в названии этой статьи. Также там базируется uavcan.rs мультитранспортная реализация на Rust, которая по состоянию на июль 2020 ищет нового мейнтейнера.

Там же поддерживается Yukon десктопная программа на питоне-электроне для разработки, отладки и диагностики UAVCAN сетей, представляющая собой смесь RViz, Wireshark и LabView. Раньше у нас была ещё утилита на PyQt для предыдущей экспериментальной версии протокола, но теперь она устарела безнадёжно, и усилия сосредоточены на Yukon. На форуме есть бесконечно длинные треды с обсуждениями, но дальше обсуждений мы практически не продвинулись из-за острой недостачи фронтендеров. На сегодня последнее демо выглядит так:

Некоторый интерес представляет использование API ROS поверх UAVCAN вместо DDS. Смысл здесь в том, чтобы сделать развитую экосистему пакетов ROS доступной в системах реального времени и младших микроконтроллерах с использованием UAVCAN, обеспечив при этом также нативную совместимость с обычными UAVCAN устройствами, ничего не знающими о ROS. Краткая вводная дана в заметке на форуме "An exploratory study: UAVCAN as a middleware for ROS"; разыскиваются коллабораторы.

Среди множества компаний и учреждений, принимающих участие развитии стандарта, следует особо выделить NXP Semiconductors. На недавней конференции они представили неплохой доклад "Getting started using UAVCAN v1 with PX4 on the NXP UAVCAN Board", демонстрирующей, в том числе, кое-какие их новые референсы для UAVCAN приложений.

Не менее ценным партнёром является Amazon Prime Air со своим крутейшим автономным доставочным дроном. Эти господа производят не железо, а код копирайты Амазона щедро разбросаны по нашим исходникам.

Законченное UAVCAN-совместимое железо вроде сервоприводов, приводов электромоторов, системы воздушных сигналов, автопилотов, систем впрыска топлива, всевозможных датчиков и отладочных плат сегодня предлагают многие вендоры, чьё перечисление тут вряд ли оправданно.

Согласно опросу, проведённому в конце 2019 года, а также основываясь на наших личных контактах с интеграторами, UAVCAN сегодня применяется в пилотируемых (~10% компаний) и беспилотных (~80% компаний) летательных аппаратах, в малых космических аппаратах (~5% компаний, на 2020 год на орбите есть около 20 кубсатов, согласно доступным нам данным), в микро транспорте (вроде электросамокатов) и разнообразных робототехнических системах. Наша выборка, впрочем, подвержена систематической ошибке и приводится только в общеинформативных целях; распределение может не соответствовать действительности. Краткая сводка по опросу доступна отдельно.

Статус и будущее проекта

Наша глобальная амбициозная цель-максимум: стать полноценной альтернативой технологиям класса DDS для отказоустойчивых высоконадёжных систем реального времени; стать стандартом де-факто для новых видов интеллектуального транспорта.

Согласно опросу, главным препятствием на пути к цели являются проблемы не технические, а социальные: 47% респондентов в последнем опросе указало, что главным препятствием на пути внедрения UAVCAN в новых разработках является низкая представленность технологии в профессиональном дискурсе. Вероятно, просветительские публикации вроде этой проекту помогут.

uavcan.org

Совсем недавно в нашем блоге публиковалась статья о новой гибридной процессорной архитектуре Alder Lake от Intel. У процессоров на ее основе есть рабочее название Core-1800 SKU, но оно вряд ли будет финальным. Образцы новых чипов удалось изучить, они включают 8 высокопроизводительных ядер Golden Cove и 8 энергоэффективных ядер Gracemont.

Базовая тактовая частота чипа 1,8 ГГц. Но с включенным TurboBoost процессор сможет показать гораздо большую производительность, вплоть до 4,6 ГГц. Известно также, что новое поколение процессоров будет устанавливаться в новый сокет Socket V (LGA1700). Это касается как чипов Intel Alder Lake-S, так и следующего поколения, Raptor Lake-S. Что это значит? Полная несовместимость процессоров со всеми выпущенными на данный момент материнскими платами и системами охлаждения.

Предстоят новые траты

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

Процессоры тоньше, чем предыдущее поколение, но зато длиннее и шире. Разработчики добавили в новинку новую теплораспределительную крышку. Чуть уменьшена и толщина сокета. Разница в размерах не так и велика всего около 1 мм, но ее придется учитывать.

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


Владельцу ресурса IgorsLAB удалось получить чертежи новых систем. Он подтвердил их несовместимость с существующими системами. В то же время, он связался с предсвителями Cooler Master, которые предоставили систему охлаждения MasterLiquid ML360 Sub-Zero. Ее удалось установить, причем результаты охлаждения были весьма неплохими. Но проблема здесь в том, что сама эта система потребляет большое количество энергии не меньше, чем сам процессор.


Выше фотография этой системы. Автор подчеркивает, что все это чистой воды эксперимент, который вряд ли пригодится для реальных кейсов.

Не все так плохо

Если перед владельцем новой системы не стоит цель использовать все ресурсы процессора, то, возможно, ему не придется покупать новую систему охлаждения вместе с платой и самим процессором. Дело в том, что Intel планирует комплектовать свои чипы базовой системой охлаждения. Но ее возможностей хватит лишь для отвода тепла от процессора, работающего на штатных частотах. Будет ли радиатор кулера оснащаться медными вставками неясно.

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


Примеры таких систем есть, подобный подход применялся, например, компанией Noctua для некоторых модификаций систем охлаждения, несовместимых с сокетами AM4. Кулер Noctua NH-U9S, например, не подходит для установки на этот сокет. Но компания выпустила специальные крепежные адаптеры NM-AM4-UxS, которые решают эту задачу.


И если система охлаждения стоит около 7000 рублей, то крепежный адаптер к ней всего 540. Вполне может быть, что прямо сейчас китайские производители уже проектируют переходники под новые платы для старых систем охлаждения ведь размерность и спецификации уже известны.

Что известно о новых процессорах

Сейчас появилась информация о размерах нового сокета. Вместо квадрата со сторонами длиной 37,5мм это будет прямоугольник с длинами сторон 35.545.0 мм.


У 12-го поколения процессоров от Intel несколько модификаций, точнее, семейств:

• Alder Lake-S для десктопных ПК.
• Alder Lake-P для мощных ноутбуков.
• Alder Lake-М для маломощных устройств.
• Alder Lake-L для мобильных девайсов.
• Alder Lake-N для всех прочих устройств, включая не очень производительные ноутбуки, хромбуки и т.п.

Отличаются они друг от друга разным же количеством ядер. К примеру, у маломощных чипов будет больше энергоэффективных ядер Atom, у процессоров для производительных систем больше высокопроизводительных ядер Core. У чипов для игровых ноутбуков и десктопных ПК только Core, что позволит добиться максимальной производительности.

В однопоточном режиме процессоры смогут обеспечивать двукратный рост производительности по сравнению с предыдущим поколением, Rocket Lake. В многопоточном все не так радужно, но и здесь прирост производительности составит около 20%, что весьма неплохо.


Новые чипы должны появиться в конце 2021 года, именно тогда ожидается их отгрузка вендорам разного рода компьютерных систем. Устройства же на основе процессоров 12-го поколения появятся в начале 2022 года, возможно, чуть позже.

Источник

Технология WebRTC (Web Real-Time Communications), которая описывает передачу аудио-, видеоданных и контента между браузерами без установки дополнительных расширений, получила статус рекомендованного стандарта. Об этом объявил консорциум W3C, который разрабатывает и внедряет технологические стандарты для сети интернет.

Все стандарты W3C проходят проверку на предмет поддержки доступности веб-контента, которая осуществляется APA (рабочей группой по архитектурам доступных платформ). Они напрямую связаны с обеспечением веб-доступности.

Помимо прочего, комитет IETF (Internet Engineering Task Force), который занимается развитием протоколов и архитектуры интернета, опубликовал документы с описанием архитектуры, элементов протоколов, видов транспорта и механизмов коррекции ошибок WebRTC. Все эти данные получили статус Предложенный стандарт.

О WebRTC

Технология позволяет веб-приложениям и сайтам захватывать и выборочно передавать аудио- и видеопотоки, а также обмениваться данными между браузерами без использования посредников. Именно благодаря ей мы можем созваниваться с коллегами на удаленке без необходимости устанавливать плагины и другое ПО. Приложения, созданный на основе этого стандарта, обрабатывают голосовой и видеотрафик в реальном времени, используя только HTML и JavaScript. По нему, например, работают Google Meet и еще ряд приложений для веб-конференций.

Технология WebRTC развивается компанией Google с 2009 года. В 2011 году компания открыла свои наработки и технологии обработки звука и видео, полученные при поглощении компании GIPS, разрабатывающей системы цифровой обработки сигналов. Тогда же Google предоставил безвозмездный доступ к патентам, связанным с WebRTC.

WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов. Процесс стандартизации технологии Google начал совместно с такими компаниями, как Mozilla, Microsoft, Cisco и Ericsson.

К слову, WebRTC (как и HTML5) стал одной из причин смерти технологии Flash. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология исчезла с рынка. О последствиях мы уже писали в блоге.

Сейчас технология WebRTC занимает второе место в топе протоколов видеосвязи после проприетарного Zoom. Стандартным протоколам H.323, SIP, Microsoft Teams и Cisco Webex пока не удается достичь ее успеха.

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

Преимущества стандарта

• Не требует установки программного обеспечения и плагинов.
• Использование современных аудио- и видеокодеков; как следствие высокое качество связи.
• Защищенные и зашифрованные соединения по протоколам DTLS и STRP.
• Есть встроенный механизм захвата контента (демонстрация рабочего стола)
• Гибкость реализации интерфейса управления на основе HTML5 и JavaScript.
• Открытый исходный код.
• Универсальность: приложение на основе стандарта хорошо работает на любой ОС, если браузер поддерживает WebRTC.

Недостатки стандарта

Для кого-то эти недостатки не будут существенными, но мы их все-таки обозначим.

• Стандарт не поддерживает удаленное управлением рабочим столом. То есть мы можем показать презентацию или график коллегам, но поработать вместе над составлением годового отчета не получится. Все ради безопасности: код Javascript не может управлять чем-либо за пределами текущего окна браузера. Для расширенных возможностей нужно использовать специально разработанные приложения.
• Приложения на WebRTC несовместимы между собой, именно поэтому мы не можем позвонить c Google Meets на какой-нибудь BigBlueButton. Но, может, это и не надо?
• Еще один недостаток состоит в том, что WebRTC определяет IP-адреса пользователей. Прокси и Tor c проблемой не справятся, скрыться помогут только VPN-сервисы.

Работа технологии на примере звонка между двумя абонентами через браузер. Источник

Из чего состоит WebRTC

На структурном уровне это:

• системы управления пользовательскими сеансами;
• движок для обработки звука: можно использовать разные кодеки и методы подавления шумов;
• движок для обработки видео;
• транспортный уровень: для передачи данных можно использовать протоколы DTLS и SRTP совместно с технологиями организации P2P-каналов связи.

Как мы уже писали ранее, работать с возможностями WebRTC можно через специально подготовленный JavaScript API. API включает в себя такие интерфейсы, как getUserMedia, RTCPeerConnection, RTCDataChannel и getStats.

Интерфейс getUserMedia отвечает за получение аудио и видео из подключенных устройств типа веб-камеры и микрофона или файла. За установку соединения между пользователями, обработку сигналов и защиту канала связи отвечает интерфейс RTCPeerConnection. Обмениваться данными во время конференции помогает RTCDataChannel (с использованием типового API WebSockets). За статистикой к интерфейсу getStats.

Что дальше

На данный момент стандартизированы только базовые части WebRTC. А что можно ожидать в следующей версии стандарта?

• Расширение, которое позволит использовать протокол QUIC в качестве транспорта и видеокодека AV1.
• API WebTransport, упрощающего организацию потокового вещания для нескольких получателей.
• API Scalable Video Coding, адаптирующий видеопоток под пропускную способность клиента.
• Сквозное шифрование видеоконференций.
• Live-обработка аудио- и видеопотоков, в том числе с помощью систем машинного обучения.
• Инструменты для установки постоянного канала связи с умными устройствами.