Основным российским и международным стандартом по функциональному анализу в предметной области
проектирования АЭС является [1]. При этом понятие функционального анализа -- вместе с напрашивающимся понятием функции – он заимствует из [2], где они определены следующим образом:
«3.27 функциональный анализ (functional analysis): Изучение функциональных целей системы с точки зрения имеющегося количества рабочей силы, технологии и других ресурсов в целях формирования основы для определения того, как и кем может быть выполнена каждая функция.
3.28 функция (function): Некоторая цель или задача, подлежащая выполнению, которую можно определить или описать, не указывая физические средства для ее достижения.»
Определение функции как «цели или задачи» достаточно необычно. Согласно [3],
«Фу́нкция ( лат.
Functio — «исполнение, совершение; служебная обязанность») — отношение между элементами, при котором изменение в одном элементе влечёт изменение в другом» что более соответствует общепринятому пониманию.
Стандарт [1] дополнительно запутывает этот вопрос. С одной стороны, поскольку функциональный анализ
должен иметь отношение к каким-то функциям, он определяет эти функции неявно, через следующее определение, которое касается уже только функций управления:
«3.5 функция управления (control function): управляющие действия, включая связанные с ними сбор и обработку информации, выполняемые людьми и машинами для достижения функциональной цели
1)
.»
При этом в предлагающейся сноске указано:
«1) Настоящее определение отличается от определения, данного в МЭК 60964, однако при этом отражает современное использование данного понятия.»
В любом случае, определение функционального анализа как «изучение целей» не выглядит как некоторая конструктивная деятельность – непонятны его задачи и ожидаемые результаты.
Несколько иначе, в чём-то более удачно, функциональный анализ определяется в области системной инженерии, откуда он собственно и появился.
В частности, в [4] приведено такое определение (приводится в переводе и в форме, отредактированной для
большей цельности):
1

«Функциональный анализ является шагом в реализации процесса системного проектирования. Он выполняется на этапе концептуального проекта и заключается в определении системы в «функциональных» терминах.
Функции сначала определяются как потребности/задачи и вместе с основными требованиями к системе. Затем определяются эксплуатационные требования к системе и концепция её обслуживания, а функциональный анализ расширяется, чтобы установить базовую концепцию функционирования, из которой определяются требования к ресурсам системы (включая оборудование, программное обеспечение, средства, люди, данные, различные элементы обслуживания и поддержки и т. д.).»
Важные дополнения к этому даны в [5], где функциональный анализ определён так:
«Функциональный анализ - это систематический процесс определения, описания и соотнесения функций, которые система должна выполнять для достижения успеха. Это не касается того, как эти функции будут выполняться.
На ранних этапах жизненного цикла проекта функциональный анализ касается:
 функций верхнего уровня, которые должны выполняться системой;
 где эти функции должны быть выполнены;
 как часто они должны быть выполнены; а также
 при какой концепции эксплуатации и условиях окружающей среды.
Позднее на этих ранних этапах функциональный анализ переходит на более низкие уровни декомпозиции системы, чтобы определить функциональный дизайн системы и интерфейсы.»
Здесь также делается следующее важное дополнение: «Функциональный анализ имеет итерации с требова-
ниями и дизайном», что иллюстрируется на схеме (схема из того же источника [6], с переводом):
Рис. 1. Требования, анализ и синтез
2

Важным отличием этой схемы от приведенных в [1] и [2] схем алгоритмов выполнения функционального
анализа является возврат на уровень анализа требований, возможно, с непринципальной корректировкой самих этих требований.
Определения стандарта [1], приведённые в п.1.1, сразу вызывают вопросы, главным из которых является – к чему именно относятся слова «системы», «цель», «задача» ? Относятся они только к управляющей системе или также к объекту управления ?
Заметим, что, например, цели – такие как безопасная и эффективная выработка электроэнергии – в первую очередь относятся к АЭС как объекту управления, или же АЭС вместе с АСУТП.
При этом понятно разумное желание выделить проектирование АСУТП в отдельную задачу с ясной постановкой. Проблема заключается в том, что сложные объекты и их системы управления тесно связаны, варианты реализации связки «объект/система управления» разнообразны, они характеризуются большим наборами технических, ценовых и прочих характеристик. Поэтому итерационный процесс анализа требований и синтеза решения
по АСУТП (Рис. 1) как правило включается в аналогичный цикл проектирования объекта управления (в нашем слу-
чае –энергоблока или АЭС в целом).
В [1] прямо указано:
«При проектировании новой АС [атомной станции] процесс декомпозиции сверху вниз обычно выполняется для всех систем станции (т.е. для систем переноса воды, электрических систем и др.). Такая декомпозиция конечных целей на функции, назначаемые затем людям или машинам, должна быть частью общего процесса проектирования АС и не должна выполняться только лишь для проектирования пункта управления. Это позволит приступить к проектированию пункта управления уже на ранней стадии проектирования всей станции и, как следствие, избежать итераций.»
Таким образом, что согласно стандарту [1], функциональный анализ проводится не в отношении АСУТП, а в
отношении АЭС в целом.
В советской нормативной базе, отличавшейся как правило чёткостью директив, этот вопрос изложен с ещё
большей «креативностью». Например, в головных методических указаниях по созданию АСУТП [8] присутствуют
такие положения:
«Разработка предварительных математических моделей технологического процесса и измерений заканчивается составлением соответствующих математических описаний. В зависимости от принятых допущений описания представляются в форме детерминированных или стохастических соотношений. Отдельные постоянные коэффициенты этих соотношений определяются либо аналитическими, либо, если это невозможно, экспериментальностатистическими методами (параметрическая идентификация).»
Такой подход видимо был связан с амбициями разработчика документа – ЦНИИ комплексной автоматизации, но это вряд ли разумно и вообще реализуемо в отношении сложных технических объектов управления и тех-
3

нологических процессов. Такие объекты и процессы разрабатываются специалистами предметной области (физике, химии и т.п.), которые и формулируют базовые принципы и функции управления. Как раз здесь желательно провести линию разграничения полномочий и ответственности, на которой формулируется постановка задачи для специалистов по автоматизации.
Отметим, что в отрасли существует близкий к требуемому документ [7], в котором описаны требуемые функ-
ции управления безотносительно нюансов реализации в АСУТП (за некоторыми исключениями). Вопрос в том, создаётся ли данный документ хотя бы в предварительной редакции на этапе эскизного или технического проекта
АЭС, когда на его базе можно разработать архитектуру АСУТП.
Для проведения полноценного функционального анализа необходимо располагать набором компетенций, покрывающем все важнейшие аспекты анализируемого предмета (технологического объекта или его АСУ).
Этот аспект функционального анализа несколько по-разному освещается в российских и международных нормативных документах.
Представление о наборе компетенций можно получить в [1], в разделе «4.2 Основная техническая группа
для выполнения анализа и распределения функций» которого указано:
«Как правило, основная техническая группа, выполняющая анализ и распределение функций, должна включать в себя специалистов в следующих областях:
− ядерная и неядерная энергетика;
− системный анализ;
− проектирование СКУ;
− проектирование информационно-вычислительных систем;
− инженерная психология и эргономика;
− эксплуатация АС;
− разработка процедур нормальной эксплуатации и аварийных процедур.
Далее по тексту эта техническая группа будет называться «разработчик».»
Данное определение достаточно странное: в то время как стандарт относится к проектированию щитов управления, сюда включены компетенции «ядерная и неядерная энергетика» и «разработка процедур нормальной эксплуатации и аварийных процедур» (вопрос только – процедур чего?).
Полноценный функциональный анализ, как представляется, должен охватить все существенные аспекты проектируемой или модифицируемой системы.
Эти аспекты определены в [8] как виды обеспечения автоматизированных систем (АС):
4

«2. ОСНОВНЫЕ КОМПОНЕНТЫ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
…2.3 организационное обеспечение автоматизированной системы; организационное обеспечение АС: Совокупность документов, устанавливающих организаци-
AS organizational support онную структуру, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверки и обеспечения работоспособности
АС
2.4 методическое обеспечение автоматизированной системы; методическое AS methodical support обеспечение АС: Совокупность документов, описывающих технологию функционирования АС, методы выбора и применения пользователями технологических приемов для получения конкретных результатов при функционировании АС
2.5 техническое обеспечение автоматизированной системы; техническое AS hardware обеспечение АС: Совокупность всех технических средств, используемых при функционировании АС
2.6 математическое обеспечение автоматизированной системы; математическое обеспечение АС: Совокупность математических методов, моделей и алгоритмов, примененных в АС
AS mathematical support
2.7 программное обеспечение автоматизированной системы; программное AS software обеспечение АС: Совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС
2.8 информационное обеспечение автоматизированной системы; информационное обеспечение АС: Совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании
AS information support
2.9 лингвистическое обеспечение автоматизированной системы; лингвистическое обеспечение АС: Совокупность средств и правил для формализации естествен-
AS linguistic support ного языка, используемых при общении пользователей и эксплуатационного персонала АС с комплексом средств автоматизации при функционировании АС
2.10 правовое обеспечение автоматизированной системы; правовое обеспечение АС: Совокупность правовых норм, регламентирующих правовые отношения при функционировании АС и юридический статус результатов ее функционирования.
Примечание. Правовое обеспечение реализуют в организационном обеспечении АС.
2.11 эргономическое обеспечение автоматизированной системы; эргономическое обеспечение АС: Совокупность реализованных решений в АС по согласованию
AS antropotechnical support психологических, психофизиологических, антропометрических, физиологических характеристик и возможностей пользователей АС с техническими характеристиками комплекса средств автоматизации АС и параметрами рабочей среды на рабочих местах персонала АС
В ряде работ, как показано на следующей иллюстрации, предлагается добавить ещё один вид обеспечения
– метрологическое обеспечение АС:
5

Рис. 2. Виды обеспечения АС
Согласно ГОСТ Р 8.820-2013 «Государственная система обеспечения единства измерений. Метрологическое обеспечение. Основные положения»:
«3.6 метрологическое обеспечение измерений; МОИ: Систематизированный, строго определенный набор средств и методов, направленных на получение измерительной информации, обладающей свойствами, необходимыми для выработки решений по приведению объекта управления в целевое состояние.
3.7 метрологическое обеспечение объекта: Метрологическое обеспечение измерений, выполняемых на объекте.»
Безусловно, этот комплекс вопросов является важнейшей частью проекта сложного физико-технического объекта управления. В то же время датчики традиционно относят к объекту управления, отделяя их от АСУТП, поэтому вопросы, касающиеся метрологического обеспечения, можно считать частью технического обеспечения, куда входят в частности измерительные модули (аналогично включению правового обеспечения в организационное).
Отметим, что в список утверждения и согласования ранее упомянутого технологического регламента [7]
включает Концерн Энергоатом, Курчатовский институт, ОКБ «Гидропресс», Атомэнергопроект и ВНИИАЭС.– набор вполне достаточный по компетенциям.
3.3.1
Функционально-стоимостной анализ
Из перечисленных аспектов анализа странным образом выпала коммерческая сторона вопроса. Между тем это является очевидно важным фактором для принятия решений.
К настоящему времени это анализ именуется как «функционально-стоимостной анализ» и определяется метод системного исследования функций объекта с целью поиска баланса между себестоимостью и полезностью
[10].
6

3.3.2
Анализ отказов и рисков
Существует также группа методов анализа, связанных с отказами и рисками, в т.ч.:

Предварительный анализ опасности, PreliminaryHazard Analysis (PHA): Совокупность приемов идентификации опасности и анализа частот, используемых на ранней стадии проектирования с целью идентификации опас-
ностей и оценки их критичности [11], [12]

Анализ видов и последствий отказов (FMEA), а также Анализ видов, последствий и критичности отказов
(FMECA): Совокупность приемов идентификации главных источников опасности и анализа частот, с помощью которых анализируются все аварийные состояния данной единицы оборудования на предмет их влияния, как на
другие компоненты, так и на систему в целом [11], [13]

Анализ дерева неисправностей (отказов), Fault Tree Analysis (FTA): Совокупность приемов идентификации опасности и анализа частот нежелательного события, с помощью которых определяются все пути его реализации.
Используется графическое изображение [11], [14]

Исследование опасности и связанных с ней проблем, Hazard and operability studies (HAZOP): Совокупность приемов идентификации фундаментальной опасности, при помощи которых оценивается каждая часть системы с целью обнаружения того, могут ли происходить отклонения от назначения конструкции и какие последствия это
может повлечь [11], [12]

Анализ влияния человеческого фактора, Human Risk Assessment (HRA): Совокупность приемов анализа частот в области воздействия людей на показатели работы системы, при помощи которых определяется влияние
ошибок человека на надежность [11]
Представляется, что эта методы анализа и стандарты, на которых они основаны, должны быть включены в рассмотрение при проведении функционального анализа.
Как ни странно, только вышеизложенные соображения позволяют более понятно сформулировать цель функционального анализа (что вообще то следовало бы сделать в само начале).
В работе [15] это формулируется следующим образом:
«… цель функционального анализа – выявить альтернативные средства достижения желаемой эффективности, выявить области, в которых имеется возможность для оптимизации различных критериев, например, стоимости, надежности и т.д., выделить альтернативные цепочки конструкторских и проектных решений».
В развитие приведённой выше цитаты, в [16] эта цель сформулирована следующим образом (хотя речь идёт
о системном анализе, она также справедливо относится и к функциональному анализу и, главное, указывает на получателя результатов этой работы):
«Одна из задач системного анализа заключается в раскрытии содержания проблем, стоящих перед руководителями, принимающими решения, настолько, чтобы им стали очевидны все основные последствия решений и их можно было бы учитывать в своих действиях. Системный анализ помогает ответственному за принятие решения
7

лицу более строго подойти к оценке возможных вариантов действий и выбрать наилучший из них с учетом дополнительных, неформализуемых факторов и моментов, которые могут быть неизвестны специалистам, готовящим решение».
Положительная сторона такой формулировки состоит ещё и в том, что она не рассматривает в качестве цели предложение единственного проектного варианта. В ходе функционального анализа могут предлагаться варианты реализации, может указываться, почему был выбран тот или иной вариант с оценкой его сторон, соответствующих рисков и т.п.
Описание целей функционального анализа и требуемых для этого компетенций в области проектирования
АСУТП АЭС порождает практический вопрос о том, каким образом этот вопрос решён в РФ.
В настоящее время организация работ по созданию проекта АЭС и АСУТП АЭС как правило включает следующих основных участников:

Атомстройэкспорт: заказчик

Курчатовский институт: научный руководитель

Гидропресс: разработчик реакторной установки

АЭП: проектная организация

РАСУ: разработчик АСУТП
Прочие организации являются поставщиками компонентов, выполняют функции строителей, пусконаладки, эксплуатации и т.д.
В такой кооперации вряд ли можно указать организацию, обладающую всеми компетенциями, указанными в разделах 3.1-3.2. Каждая из перечисленных организаций владеет лишь частью аспектов, а для выработки компромиссных решений необходим авторитетный арбитр. Кроме того, недостатком такой команды является отсутствие надёжной обратной связи по результатам проекта – всё перечисленные итерационные процессы из раздела
1.2 (см. Рис. 1) имеют более значимый цикл итерации проекта по результатам эксплуатации.
Представляется, что такой – условной говоря головной – должна выступать организация, которая хотя бы частично должна обладать всеми компетенциями, необходимыми в проекте. Наиболее предпочтительным участником может выступить ВНИИАЭС, который всесторонне знаком с тематикой проектов и, что очень важно, по своему прямому назначению занимается анализом результатов эксплуатации.
1.
ГОСТ Р МЭК 61839 – 2011. Атомные станции. Проектирование пунктов управления. Функциональный анализ и распределение функций
2.
ГОСТ Р МЭК 60964-2012. Атомные станции. Пункты управления. Проектирование
3.
Философский словарь / СПб. 1911.
4.
John E. Blyler, Benjamin S. Blanchard. System Engineering Management, 5th Edition, Wiley, 2016
8

5.
Sage, A.P. and Rouse, W.B. (eds.). Handbook of Systems Engineering and Management, Wiley, New York, 1999
6.
Krishna Kumar. Functional Analysis Module. Space Systems Engineering, Ryerson University / NASA, 2015
7.
Типовой технологический регламент безопасной эксплуатации энергоблока АЭС с реактором ВВЭР-1000 (В-
320)»
8.
Общеотраслевые руководящие методические материалы по созданию и применению автоматизированных систем управления технологическими процессами в отраслях промышленности (ОРММ-З АСУТП) / Государственный комитет СССР по науке и технике, 1986
9.
ГОСТ 34.003-90. Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
10.
https://ru.wikipedia.org/wiki/Функционально-стоимостный анализ
11.
ГОСТ Р 51901.1-2002 (МЭК 60300-3-9:1995) Менеджмент риска. Анализ риска технологических систем
12.
ГОСТ Р 51901.11-2007 (МЭК 60812:2006) Менеджмент риска. Исследование опасности и работоспособности.
Прикладное руководство. Risk management. Hazard and operability studies. Application guide
13.
ГОСТ Р 51901.12-2007 (МЭК 60812:2006) Менеджмент риска. Метод анализа видов и последствий отказов
14.
ГОСТ Р 51901.13-2005 (МЭК 61025:1990) Менеджмент риска. Анализ дерева неисправностей
15.
А.А. Просвирнов, Т.Просвирнова. Системный функциональный анализ как базис концептуального проектирования / Системная инженерия. Управление жизненным циклом, http://www.seplm.ru/
16.
Голубков Е.П. Системный анализ как методологическая основа принятия решений / «Менеджмент в России и за рубежом», №3 / 2003
9