Когда я была маленькой, мне казалось, что инженеры – это такие люди, которые днями и ночами напролёт что-то выдумывают, чертят или что-то собирают руками. Даже свою будущую профессию я выбрала с мыслью: «О! Какой красивый самолёт, как юрко летает. Я хочу создавать такую же красоту».
С тех пор прошло около 8 лет, сегодня я инженер-конструктор 3 категории и могу сказать, что маленькая Катя была права, но лишь частично. В конце концов, инженеры все разные, методы работы у нас тоже могут различаться, так какой же я инженер?
Я принадлежу к группе разработчиков систем воздушного судна и комплексов бортового оборудования (КБО). Как выразилась моя бывшая начальница: никто до конца не понимает, чем мы занимаемся, но мы знаем всё и про всех. Мы те люди, кто уже на этапе идеи будет работать с желаниями заказчика. Например заказчик скажет: «Я хочу, чтобы вертолёт долетел из пункта А в пункт В, но со следующими условиями». Мы принимаем от него большое техническое задание (ТЗ) и начинаем думать: как воплотить все «хотелки» заказчика и можем ли мы их воплотить.
На момент начала нашей работы никто не знает «как сделать правильно». Это мы должны знать различные ГОСТы, документы ИКАО, приказы Минтранса, регулирующие воздушное пространство. Зачем нам это знать? Потому что от этого будет зависеть, что мы идеологически заложим в системы вертолёта. А если идея заказчика противоречит нормам? Тогда мы начинаем переговоры с руководством проекта и с заказчиком, чтобы прийти к единому мнению: как выполнить текущие задачи проекта, как соблюсти требования и нормы и как всё оборудование будет «общаться».
Давайте разберёмся на более приземлённых примерах. Я буду говорить о задачах приближенных к реальности, но без особых деталей.
Разработка нового функционала
В ТЗ обычно указывают всё, что хотят от работы комплекса. Нужно понимать, что для полноценного выполнения пункта ТЗ потребуется работа нескольких групп специалистов:
- Эргономистов, которые придумают, как пилот будет взаимодействовать с машиной и наоборот;
- Специалистов моей группы, которые придумают логику работы комплекса, определят перечень параметров, которыми необходимо управлять, оценят потери данных, если такие имеются, и в случае критичности их потери придумают, откуда и как их достать. Словом, проведут полноценное теоретическое “расследование”, предоставят результаты;
- Специалистов, которые занимаются подготовкой требований к программному обеспечению. Они досконально знают реальные вычислительные возможности наших устройств, потому что мы, как идеологи, можем навешать на один, например, индикатор множество функций, а нам скажут: «Нельзя, нам на такое мощностей не хватит, да и свободного места в памяти нет». Эти ребята заставят мою группу пересмотреть свою идею и доработать её под возможности устройств;
- Специалистов по отказобезопасности, которые будут оценивать, что будет происходить с системами при выполнении этой функции. Т.е. они посмотрят влияние этой функции на безопасность работы, оценят возросшую нагрузку на оборудование с точки зрения надёжности, присвоят категорию критичности отказа, сверяться с разными стандартами и только в том случае, если их расчёты показывают, что наша задумка или отказ соответствующего оборудования не приводит к опасным ситуациям, что это всё вписывается в определённые значения, тогда и только тогда нашу идею можно начинать воплощать;
- Программистов, до которых уже спускается конкретная задача «что закодить». Они уже посмотрят содержание задачи, наработки предыдущих специалистов по этому вопросу, в том числе и наши документы, после чего смогут написать необходимую часть кода;
- Испытателей, которые должны до установки на борт, а иногда и на борту, проверить, так ли всё работает, как было заложено ещё моей группой или нет. Если работает не так, тогда испытатели придут к нам со словами: «Ребят, оно так не работает, мы предполагаем, что причина в этом и этом, рассмотрите».
Думаю, суть вы уловили. Каждый инженер/программист занят своим делом, а моя группа даёт пинок, чтобы эта машина заработала.
Мы, можно сказать, идеологи, но и наши идеи могут возвращать на доработку и тогда цикл разработки будет повторяться из раза в раз, пока не дойдём до успешной реализации.
Кто я? Идеолог? Организатор? Инженер?
Представители моего отдела – в том числе и переговорщики, как я писала во вступлении. Мало того, что мы что-то придумываем, на нас лежит много документов на согласовании. Это значит, что у моих коллег может рабочей день уйти на то, чтобы постоянно разговаривать с заказчиком, компаниями-соисполнителями КБО, коллегами из других отделов, чтобы согласовать изменение, условно, в одном бите одного из адресов (об «адресах» советую познакомиться в статье об интерфейсах) или одну линию между двумя контактами на схеме.
Когда ты ещё только техник или «маленький инженер», конечно, такие переговоры ведут «старшие», но со временем даже я могу позвонить или написать в компанию-соисполнитель и спросить: «Коллеги, в рамках текущего проекта работаю с протоколами и руководствами, которые касаются ваших изделий, выявила несоответствие. Не могли бы вы прояснить следующие моменты?»
Так мы выясняем, что где-то в документы залетел пустой бит, где-то физически другое подключение, а где-то оригинальные логики работы и руководства имеют в своём содержании противоречия, которые также устраняются по результатам нашего обращения к изготовителям оборудования, которое мы вводим на борт воздушного судна.
И не забываем про то, что как разработчикам нам нужно уметь ставить задачи перед людьми, что выражается как во внутренних задачах нашего производства, запускающие цикл разработки как на рисунке 1, так и, например, создание такого документа как Технические требования к изделию, чтобы оборудование компаний-соисполнителей в точности соответствовало требованиям технического задания.
Клуб умников и умниц
Как я говорила ранее, представители моей группы разработчиков – те, кто лучше всех знает, как должен работать Комплекс. Чуть что, именно в мой отдел зайдут ребята из других отделов и спросят: «А мы не поняли, как вы себе это представляете. Почему так?». И заказчику ведь тоже надо объяснять, как у нас работает КБО, и как он выполняет поставленные задачи. Так мы создаём документ «Логика работы комплекса», где учитывается всё. Это огромный документ на 100+ страниц, который получает заказчик, а иногда и пилот, который является почти инструкцией «Как это всё работает и как вам нужно с этим взаимодействовать». Например, я полгода назад подробно описывала в этом документе где и что нажать, чтобы выполнить тот или иной манёвр.
И кроме Логик мы пишем такие документы как «описание систем». Согласно ГОСТ 18675 – 2012 «Документация эксплуатационная и ремонтная на авиационную технику и покупные изделия для нее» воздушное судно делят на системы и подсистемы, которым присваивают номер. Например, 34-20 это «Подсистема информации о пространственном положении и курсе – Часть системы, которая использует магнитные, электрические, гироскопические или инерционные принципы для определения и отображения направления полета или пространственного положения воздушного судна.» В техническом задании на КБО часто есть конкретный перечень описания систем, который необходимо предоставить заказчику. Более того «Описания» помогают отказобезопасникам в их работе, поэтому ряд разделов этого документа предназначены именно для них.
Таким образом, в Описание системы инженер-конструктор, разработчик Комплекса, заложит влияние выбранной подсистемы на остальные системы ВС, состав и функционал оборудования, который относится непосредственно к выбранной подсистеме. Если брать как пример 34-20, то мы с уверенностью говорим, что в описание войдёт всё о курсовертикалях и инерциальных системах. Основную часть документа занимает описание функций подсистемы, которые в свою очередь, необходимы для выполнения функций КБО, которые ранее определили инженеры-конструкторы в моём отделе.
Для большего понимания, обратите внимание на таблицу ниже
ACFT – система воздушного судна, которая не входит в КБО и подробно не рассматривается нами, так как мы не несём ответственности за всё, что не связано с нашим КБО.
Мы описываем предложенные функции:
- как выполняется функция
- какое оборудование она затрагивает
- что влияет на нормальную работу
- как и почему можно перейти в ненормальный режим работы
- что приводит к потере функции
- какие события в итоге будут сигнализироваться экипажу, например, потеря одного из источников информации
- и т.д.
Словом, дотошно фиксируем всё, что можно о работе систем в составе КБО.
Зэ Энд
Конечно, когда в свои 15 лет я видела красивые самолёты, я думала, что буду создавать красивые фюзеляжи, но вот сначала я поступаю на «Системы управления летательными аппаратами», где понимаю, что, оказывается, вопросы манёвренности и управления мне интересны гораздо больше, пусть мне так и не смогли объяснить «кто я?». А потом я угодила чётко по специальности на работу и поняла, чему меня учили 5 лет. Для меня быть тем, кто почти с нуля придумывает идею, которую мне потом не пощупать, но она заставит вон ту красивую «железную форму» правильно летать, ещё и никого не убив, - намного интереснее, чем создавать внешний облик воздушного судна, а процесс всех мук согласования и «войн за адекватность» даже добавляет задора.
Главное, что 15-летняя Катюшка хотела стать авиационным инженером-конструктором, и она им стала.
Информация о произведении:
Автор: Екатерина Виноградова
Редактор: Сабуров Даниил
Условия использования: свободное некоммерческое использование при условии указания автора и ссылки на первоисточник.
Для коммерческого использования - обращаться на почту: buildxxvek@gmail.com