Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
А.Левенчук -- основные альфы системной инженерии в EssenceAnatoly Levenchuk
Доклад АнатолияЛевенчука «Essence для системной инженерии: опыт моделирования» на 76 заседании Русского отделения INCOSE (совместно с Русским отделением SEMAT), 22 мая 2013г.
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахAnatoly Levenchuk
Доклад Юрия Бабий "Опыт применения инструментария многокритериальной оптимизациии для повышения эффективности сложных технических систем" на 65 заседании Русского отделения INCOSE, 24 октября 2012г.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
А.Левенчук -- основные альфы системной инженерии в EssenceAnatoly Levenchuk
Доклад АнатолияЛевенчука «Essence для системной инженерии: опыт моделирования» на 76 заседании Русского отделения INCOSE (совместно с Русским отделением SEMAT), 22 мая 2013г.
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахAnatoly Levenchuk
Доклад Юрия Бабий "Опыт применения инструментария многокритериальной оптимизациии для повышения эффективности сложных технических систем" на 65 заседании Русского отделения INCOSE, 24 октября 2012г.
Б.Позин -- катастрофоустойчивая банковская система (2/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (2/2) на 80 заседании Русского отделения INCOSE, 25 сентября 2013г.
Доклад Сергея Нужненко (ООО «Лаборатория системного анализа» (lab-sa.ru)) "ИТ-проекты и ИТ-результаты" на 130-м заседании Русского отделения INCOSE, 9 ноября 2017 г.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
Основные альфы системной инженерии (Systems engineering Essence)Anatoly Levenchuk
Доклад А.Левенчука "Основные альфы системной инженерии (Systems Engineering Essence)" на конференции «Актуальные проблемы системной и программной инженерии», 7 июня 2013 (Москва, МЭСИ).
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017Alexander Shamanin
Доклад Вячеслава Мизгулина (к.т.н., ИТ-консультант, Доцент кафедры интеллектуальных информационных систем УрФУ, Руководитель программы магистратуры "Системная инженерия" Инженерной школы новой индустрии УрФУ, Казначей Русского отделения INCOSE)
-- Результаты работы на INCOSE WS 2017
1. Общий обзор мероприятия INCOSE WS 2017 и рефлексия "по горячим следам".
2. Стратегия INCOSE и пути развития Русского отделения INCOSE, интерес к Русскому отделению.
3. Перевод INCOSE Handbook и перспективы сертификации на русском языке, тренинги и образовательные программы.
4. Краткий обзор деятельности некоторых рабочих групп - возможность подключиться к международной деятельности:
- MBSE
- PM-SE
- Systems science
- Requirement engineering
- Agile SE and Systems science
- и т.д.
5. Методологии работы на воркшопах.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
Алексей Иванов -- курс по стыку системной и программной инженерийAnatoly Levenchuk
Доклад Алексея Иванова «Стык системной и программной инженерии в учебном курсе моделеориентированной разработки программоёмких систем» на 75 заседании Русского отделения INCOSE, 24 апреля 2013г.
Б.Позин -- катастрофоустойчивая банковская система (1/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (1/2) на 78 заседании Русского отделения INCOSE, 10 июля 2013г.
Б.Позин -- катастрофоустойчивая банковская система (2/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (2/2) на 80 заседании Русского отделения INCOSE, 25 сентября 2013г.
Доклад Сергея Нужненко (ООО «Лаборатория системного анализа» (lab-sa.ru)) "ИТ-проекты и ИТ-результаты" на 130-м заседании Русского отделения INCOSE, 9 ноября 2017 г.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
Основные альфы системной инженерии (Systems engineering Essence)Anatoly Levenchuk
Доклад А.Левенчука "Основные альфы системной инженерии (Systems Engineering Essence)" на конференции «Актуальные проблемы системной и программной инженерии», 7 июня 2013 (Москва, МЭСИ).
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017Alexander Shamanin
Доклад Вячеслава Мизгулина (к.т.н., ИТ-консультант, Доцент кафедры интеллектуальных информационных систем УрФУ, Руководитель программы магистратуры "Системная инженерия" Инженерной школы новой индустрии УрФУ, Казначей Русского отделения INCOSE)
-- Результаты работы на INCOSE WS 2017
1. Общий обзор мероприятия INCOSE WS 2017 и рефлексия "по горячим следам".
2. Стратегия INCOSE и пути развития Русского отделения INCOSE, интерес к Русскому отделению.
3. Перевод INCOSE Handbook и перспективы сертификации на русском языке, тренинги и образовательные программы.
4. Краткий обзор деятельности некоторых рабочих групп - возможность подключиться к международной деятельности:
- MBSE
- PM-SE
- Systems science
- Requirement engineering
- Agile SE and Systems science
- и т.д.
5. Методологии работы на воркшопах.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
Алексей Иванов -- курс по стыку системной и программной инженерийAnatoly Levenchuk
Доклад Алексея Иванова «Стык системной и программной инженерии в учебном курсе моделеориентированной разработки программоёмких систем» на 75 заседании Русского отделения INCOSE, 24 апреля 2013г.
Б.Позин -- катастрофоустойчивая банковская система (1/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (1/2) на 78 заседании Русского отделения INCOSE, 10 июля 2013г.
Доклад Михаила Бухарина "Разбивка на модули в архитектурном проектировании. Практика DSM (design structure matrix)" на 94 заседании INCOSE, 8 октября 2014г.
Talk of Ali Mousavi "Event-Modelling An Engineering Solution for Control and Analysis of Complex Systems" at 116th regular meeting of INCOSE Russian chapter, 14-Sep-2016
Доклад Михаила Гайворонского "Опыт разработки САУ (FADEC) двигателя в соответствии с требованиями стандарта DO-178" на 115 заседании Русского отделения INCOSE, 25 мая 2016г.
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...Alexander Shamanin
Tim Weilkiens (Тим Вайлькинс ) "Системная инженерия: консалтинг, магистерская программа и работа с INCOSE в Германии (oose)/ Systems engineering: consulting services, masters curriculum and INCOSE collaboration (oose
Доклад А.Левенчука "Инженерия систем с плохой модульностью и гранулярностью: предприятия, искусственные нейросети, психика" на 112 заседании Русского отделения INCOSE, 23 марта 2016г.
Доклад Марка Акоева (Уральский федеральный университет) "Системная динамика как вид системного мышления" на 119 заседании Русского отделения INCOSE, 26 октября 2016г.
В.Мизгулин -- программа магистратуры по системной инженерииAnatoly Levenchuk
Доклад В.Мизгулина "Программа магистратуры по системной инженерии" на 7й рабочей встрече Русского отделения INCOSE по проблемам системной инженерии, 23 апреля 2016г.
Интегрированный подход к управлению информацией жизненного цикла антропогенн...Сергей Волков
Презентация к защите серии стандартов "Интегрированный подход": ГОСТ Р 57269-2016, ГОСТ Р 57295-2016, ГОСТ Р 57296-2016.
Презентация показывает ключевые особенности интегрированного подхода при анализе и разработке проектов.
Доклад В.Аленькова "Подходы к архитектуре управления жизненным циклом сложного инженерного объекта" на 46 заседании Русского отделения INCOSE 13 июля 2011г. (1/2)
Everyone knows that the whole is much bigger than the sum of individual parts. This applies fully to the AiCare service.
The main purpose of the service is to free the user from configuring and controlling MEP systems, minimize design stage activities, and to ensure the facility operates as smoothly as possible. The AiCare service performs intellectual monitoring of such systems as "Smart House", "Smart Building", "Smart City" by automatically performing activities related to the collection, analysis, classification of information about the facility, including user skills and preferences, and control law adaptations in order to ensure maximum efficiency and create a comfortable environment.
The service is based on methods for the automatic merger of different components under a single control platform:
• techniques for the coordinated automated control of the facility's heterogeneous MEP systems;
• systems for the accumulation and actualization of information on facility user preferences;
• systems for the accumulation and actualization of information on physical properties of facility elements;
• methods for the statistical analysis of incoming information and synthesis of platform control laws;
• mechanisms for the individual adaptation of control laws as information is compiled on the facility and its users.
This approach results in a synergy — a brand-new level of coordinated control efficiency. Control laws created by the service are coordinated with the actual composition of the facility's systems, their behavior and the users' actions over time, and they automatically adapt as changes occur.
The service, provided in the external control mode, complements existing possibilities of the facility and ensures a whole new level of productivity and efficiency of its systems. An innovative approach to big data processing and the use of "cloud computing" for resource-intensive mathematical control models provides a user-friendly, secure, highly productive and resource efficient environment that requires minimum management by the facility's user.
Интеграция высокоуровневых технико-экономических моделей системы, её окружения и жизненного цикла для "типового проекта"Стадии инженерии требований и определения архитектурных развилок
Стадии инженерии требований и определения архитектурных развилок
Виктор Агроскин
ТехИнвестЛаб.ру
RuSEC 2010
6 апреля 2013 г. в омском филиале Luxoft прошел пятый IT-субботник – открытая встреча для IT-специалистов. Максим Юнусов, тренер Luxoft Training по анализу и проектированию ПО, представил доклад «Архитектура в Agile проекте».
В своем выступлении Максим рассказал об архитектуре в «раннем» и в «развитом» Agile, принципах дизайна, мифе о рефакторинге и факторах качества по Бертрану Мейеру, а также о качествах, ценных в Agile, и архитектурных взаимодействиях в Agile проектах.
Usually, software engineering changes appear with a 10-15 year lag in systems engineering as a general practice. Therefore we can reliably predict what will be changed in the systems engineering mainstream in the nearest future and perform these practices today rather than tomorrow. There are a lot of changes: systems architecture established itself as a new separate discipline that deals with -ilities as architectural concerns/characteristics, requirements engineering disappears, manufacturing operates by developers (DevOps concept), and ubiquitous usage of continuous development and continuous delivering principles. The presentation gives an overview of these changes reflected in the "Systems engineering 2022" textbook published by Anatoly Levenchuk a couple of months ago.
Слайды лекции по современной методологии в составе интеллект-стека как идущей на смену праксиологии, на базе которой были сделаны наработки австрийской школы экономики.
Доклад А.Левенчука "SysArchi -- системное моделирование в ArchiMate 3.0" на семинаре "Дни инженерии организаций" факультета информатики, математики и компьютерных наук НИУ ВШЭ. Москва-Нижний Новгород, 11 сентября 2018
Доклад А.Левенчука "Системное мышление за пределами инженерии и менеджмента. Пример: системный фитнес" на конференции "Системный менеджмент" Школы системного менеджмента и Русского отделения INCOSE, 16 апреля 2017г.
Алексей Иванов -- мультиагентные архитектуры в электроэнергетике
1. Мультиагентные архитектуры в электроэнергетике
Основания мультиагентности
к 81-му заседанию Русского отделения INCOSE
Москва, 09.10.2013
Иванов Алексей, amivanoff@gmail.com
главный специалист
Центр системных исследований и разработок
интеллектуальных энергосистем
НТЦ ФСК ЕЭС
2. 09.10.2013 2
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
3. 09.10.2013 3
Заинтересованные лица: Консенсус о целесообразности
перехода к интеллектуальной энергетике достигнут
• Масштабное развитие распределенной генерации
• Новые требования потребителей («цифровой» спрос)
• Госполитика повышения эффективности
• Неиспользованные возможности новых технологий
• Глобализация энергетических рынков и инфраструктур
4. Продолжается дискуссия о способах перехода к
интеллектуальной энергетике
09.10.2013 4
«SMART GRID» – информатизация, автоматизация управления
«ААС» – изменение идеологии и практики управления
5. Ключевые требования к развитию инфраструктуры определены
1. Безлюдность, Self-*
Саморегулирование, непрерывный самоконтроль, самовосстановление отдельных элементов или
участков сети после аварии
2. Клиенто-ориентированность
Интеграция в сеть всех типов потребителей сетевых услуг
Поддержка и мотивирование потребителей быть активными участниками электроэнергетической
системы
3. Обеспечение физической и кибернетической защищенности
4. Поддержка развития рынков электрической энергии, мощности,
формирования новых рынков сервисов для различных пользователей
5. Обеспечение качества электроэнергии, соответствующего требованиям
современной высокотехнологичной экономики
6. Оптимизация состава и повышение эффективности использования активов
электросетевого комплекса и электроэнергетики в целом
09.10.2013 5
6. Принципы создания эталонной архитектуры ИЭС ААС
• Целостность технических, кибернетических и социальных аспектов
• Технологическая нейтральность
• Модульная платформа с открытой архитектурой
• Интеллектуальность (активность) элементов системы
• Встраивание инженерии системы в саму систему
09.10.2013 6
8. Технологическая нейтральность
09.10.2013 8
Архитектуры существующих систем
Объект
сети
Сервис Сервис
Протоколы взаимодействия
Модели данных, языки описания данных, форматы
представления данных
Развивающаяся единая модель данных
Сервис Сервис Сервис
Общие сервисы
Сервис
Объект
сети
Объект
сети
Объект
сети
Интерфейс
взаимодействия
с человеком
Анализ и
Управление
Модель объекта
Управления
Интерфейс с
оборудованием
Объект
сети
Объект
сети
Объект
сети
Объект
сети
Среда модулей анализа и управления
Архитектура технологически
нейтральной платформы
Эффекты использования технологически нейтральных платформ
Стандартизированные интерфейсы
Общеотраслевая технологически нейтральная
платформа
Независимость от поставщиков отдельных решений,
совместимость новых и существующих систем
Обеспечение управляемости систем в отрасли за счет
унифицированного управления
9. Модульная платформа с открытой архитектурой
09.10.2013 9
Переход от интегрированной архитектуры к модульной
архитектуре для различных отраслей
Источник: ЦСР «Северо-Запад» по модели Utterback.
10. Интеллектуальность (активность) элементов системы
09.10.2013 10
Каждый участник мультиагентной системы управления имеет агента с набором целей и
приоритетов, заданных владельцем, который самостоятельно реагирует на изменение среды
Централизованное управление Мультиагентное управление
Обеспечение надежности управления при слабых коммуникациях и инфраструктуре хранения и обработки данных
Лучший учет специфических правил и ограничений использования оборудования, задаваемых его собственником
Облегченное развитие систем управления, самонастройка при изменении объекта управления
Исполнители
Главный
координатор
Локальные
координаторы
Децентрализованное управление
Увеличение степени децентрализации
Единственный центр принятия решений
Множество связанных центров
принятия решений Независимые центры принятия решений
Эффекты использования мультиагентного подхода
11. Технологическая нейтральность
09.10.2013 11
Архитектуры существующих систем
Объект
сети
Сервис Сервис
Протоколы взаимодействия
Модели данных, языки описания данных, форматы
представления данных
Развивающаяся единая модель данных
Сервис Сервис Сервис
Общие сервисы
Сервис
Объект
сети
Объект
сети
Объект
сети
Интерфейс
взаимодействия
с человеком
Анализ и
Управление
Модель объекта
Управления
Интерфейс с
оборудованием
Объект
сети
Объект
сети
Объект
сети
Объект
сети
Среда модулей анализа и управления
Архитектура технологически
нейтральной платформы
Эффекты использования технологически нейтральных платформ
Стандартизированные интерфейсы
Общеотраслевая технологически нейтральная
платформа
Независимость от поставщиков отдельных решений,
совместимость новых и существующих систем
Обеспечение управляемости систем в отрасли за счет
унифицированного управления
12. Встраивание инженерии системы в саму систему
09.10.2013 12
Модель
объекта
управления
Распределенный объект управления
состояние
Анализ и выработка
безопасного оптимального
воздействия
воздействиеизменение
структуры,
износ,
отказы
Перепроекти
рование
Выяснение
ситуации
13. Шаблонные решения: Мультиагентные системы
09.10.2013 13
Каждый участник мультиагентной системы управления имеет агента с набором целей и
приоритетов, заданных владельцем, который самостоятельно реагирует на изменение среды
Централизованное управление Мультиагентное управление
Обеспечение надежности управления при слабых коммуникациях и инфраструктуре хранения и обработки данных
Лучший учет специфических правил и ограничений использования оборудования, задаваемых его собственником
Облегченное развитие систем управления, самонастройка при изменении объекта управления
Исполнители
Главный
координатор
Локальные
координаторы
Децентрализованное управление
Увеличение степени децентрализации
Единственный центр принятия решений
Множество связанных центров
принятия решений Независимые центры принятия решений
Эффекты использования мультиагентного подхода
14. 09.10.2013 14
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
15. Выбор базовой эталонной архитектуры ИЭС ААС
09.10.2013 15
Критерий анализа NIST EPRI M/490 CRISP Microsoft ABB Cisco
Этап 1: Отбор архитектур по способам описания
Архитектура содержит максимально полный набор
компонентов и подсистем
Архитектура описывает процессы и функции и не
фокусируется на конкретных решениях
Этап 2: Отбор архитектур по области использования
Технологическая нейтральность архитектуры: базовая
эталонная архитектура не должна включать в себя
конкретные технологии и технологические решения
Совместимость архитектуры по географическому
признаку, используемым стандартам
Актуальность архитектуры: базовая эталонная
архитектура должна иметь наиболее актуальные на
сегодняшний момент архитектурные описания
Архитектура не должна противоречить мультиагентным
принципам управления
Архитектура должна поддерживать субсидиарность
(распределенность, многоуровневость) принятия решений
Архитектура соответствует рассматриваемому критерию Архитектура не соответствует рассматриваемому критерию
В результате рассмотрения 7 архитектур smart grid в качестве базовой эталонной
архитектуры ИЭС ААС определена европейская эталонная архитектура,
разработанная в рамках мандата M/490
16. Ключевые элементы европейской эталонной
архитектуры
09.10.2013 16
Выбор варианта
использования
Разработка
уровня
компонентов
Разработка бизнес
уровня
Разработка
функционального
уровня
Разработка
информационного
уровня
Разработка
уровня
коммуникаций
Архитектурная модель
Схема подготовлена на основе материалов CEN-CENELEC-ETSI Smart Grid
Coordination Group
Европейская концептуальная модель
Варианты использования
(Use Cases)
Концептуальная модель основана на
модели NIST с некоторыми
дополнениями, связанными со
спецификой европейской
энергосистемы:
Введен новый домен
«Распределенные энергоресурсы»
Введена концепция гибкости
архитектуры
Архитектурная модель определена
для применения к Европейской
концептуальной модели исходя из
принципов разбиения
энергоинформационных систем с точки
зрения электрических процессов и с
точки зрения управления
информацией (разбиение на
иерархические зоны (уровни)
управления электрическими
процессами)
Рекомендации
Рекомендации по
проектированию
коммуникационного
и информационного
слоя
Общие
рекомендации по
проектированию
архитектур
Методология использования архитектурной модели
17. Направления развития базовой эталонной
архитектуры
09.10.2013 17
Динамический баланс интересов
Ситуативное, сценарное достижение
целей
Адаптивное целеполагание
Открытые платформы
Распределенные гибкие функции
Реализация системных функций
через взаимодействие простых
функций
Small Data
Облачные технологии
Федерирование данных
Распределенные эволюционирующие
информационные модели
Гибкие данные
Разноуровневые коммуникации
Высокая модульность систем
Технологии динамической
модульности
Технологии распределенных
высокомодульных систем
Технологий ПЛИС
Бизнес слой
Функциональный
слой
Информационный
слой
Коммуникационный
слой
Компонентный
слой
18. Использование европейской эталонной архитектуры
в качестве базовой эталонной архитектуры ИЭС ААС
09.10.2013 18
Использование общего языка (методологии) для разработки
архитектур конкретных систем
Использование свода стандартов, регламентов, лучших
практик, обеспечивающих совместимость информационно-
коммуникационных моделей и решений (систем)
На данный момент базовая эталонная архитектура ИЭС ААС содержит:
общие принципы, стандарты, лучшие практики, концептуальные модели систем
энергетической отрасли страны
Возможность учета специфики российской энергетики в
части описания архитектур бизнеса, функциональных
моделей, оборудования
Европейская эталонная архитектура не ограничивает
возможностей развития архитектур в соответствии с
заданными требованиями (принципами)
19. Требования к развитию базовой эталонной
архитектуры
09.10.2013 19
Базовая эталонная архитектура ИЭС ААС не противоречит
принципам развития и функционирования ИЭС ААС, но при этом не
описывает реализацию всех декларируемых принципов, поэтому
необходимо:
Обеспечить инструменты реализации принципов
мультиагентных систем управления
Обеспечить дополнительное развитие принципов
модульности, открытости архитектуры
Обеспечить учет интересов независимых разнородных
субъектов электроэнергетики
20. 09.10.2013 20
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
21. Пилотные кластеры ОЭС Востока
09.10.2013 21
Солнечный
поток
VPP
Активы
Цель:
Отработка интеллектуальных средств управления
для магистральных сетей
22. Эльгауголь: проблематика
09.10.2013 22
Общие характеристики кластеров:
• Протяженные транзиты от генерации к потребителям
• Доминирование промышленной нагрузки
• Отсутствие либерализованного рынка
• Необходимость отработки комплекса функций управления
Особенности кластера Эльгауголь:
• Необходимость обеспечения резервирования энергоснабжения и
качества электроэнергии горнопроходческой и тяговой нагрузки
• Возможность отработки проектных решений для управления
режимами в условиях сложного графика тяговой нагрузки
• Относительная готовность кластера для апробации
интеллектуальных систем управления
• Возможность сравнения централизованного и децентрализованного
решения
Задачи:
• Повышение управляемости сети в условиях тяговой нагрузки
• Cнижение потерь
• Обеспечение надежного режимного управления
• Отработка гибких расширяемых технологий
23. Заинтересованные лица ПТК
09.10.2013 23
Система
ПТК
Федеральная
сетевая компания
МЭС Востока
НТЦ ФСК ЕЭС
Потребители
энергии
Служба поддержки
связи
Системный
оператор Интеграторы
Производители
оборудования
Операторы связи
ЭРГ
Архитектурный
комитет
Диспетчер
Обеспечивающая
система
АСУ ТП ПС
Оператор
агента
EMS ЦУГП
24. Заинтересованные лица ПТК
Наименование Вовлеченность в проект
НТЦ ФСК ЕЭС Выполняет проект
МЭС Востока Контролирует физическое системное окружение
Потребители кластера Возможные выгодополучатели
ФСК ЕЭС Финансирует проект
Традиционные вендоры Контролируют кибернетическое системное окружение
Новые вендоры Участвуют в разработке решения
Интеграторы Контролируют кибернетическое системное окружение
Оператор связи Возможный выгодополучатель
Системный оператор Согласовывает решение
Архитектурный комитет Формирует социальный заказ
Экспертные группы Обеспечивают экспертную поддержку
09.10.2013 24
25. Анализ требований
09.10.2013 25
Категория
сравнения
Централизованное управление Распределенное управление
Надежность Определяется алгоритмами управления
системой, требующих наблюдаемости,
управляемости и связи
Определяется распределенностью
элементов, отказ каждого не влияет
критическим образом на работу системы
Эффективность Эффективно при высокой наблюдаемости
и качестве исходной режимной и
технологической информации
Эффективность системы растет с каждым
новым функциональным агентом либо его
совершенством
Безопасность Определяется повышенными
требованиями к безопасности всех
элементов и средств связи, критична
безопасность центра
Возможность верификации внешней
информации о других агентах, исходя из
собственного представления о внешнем
окружении (сети)
Гибкость
организации ПО
Требуется перепроектирование и
разработка новых алгоритмов для
центров управления, усиления или ввода
новых каналов связи
Самонастройка группового поведения
агентов при изменении топологии сети,
включая добавление новых элементов.
26. Различие архитектурных принципов
09.10.2013 26
Требования экспертных рабочих групп
Обеспечение надежности работы систем управления при слабых
коммуникациях
Использование открытых решений, обеспечивающих легкий доступ
третьих производителей
Обеспечение легкой интеграции различных систем, обеспечение
доступа к общим ресурсам
«Нулевое перепроектирование» систем управления при развитии
Аспекты архитектуры Система Система систем
Сфера деятельности Единственная Множество
Структура Иерархическая Ячеисто-сетевая
Индикаторы Интегральный Многофакторный
Управление Централизованное Мультиагентное
Интерфейс Общесистемный Сетевой
Целеполагание Программное Адаптивное
На основе доклада В.В.Бушуева
«Энергетика как система систем»
27. Выбор архитектуры
09.10.2013 27
Категория
сравнения
Централизованное управление Распределенное управление
Основные черты Централизованная клиент-серверная
система управления нормальными
режимами (SCADA-EMS).
Сеть, равноправных узлов управления.
Каждый узел - клиент-сервер. В такой сети
решения о регулировании узлы управления
принимают, исходя из внутренней и внешней
информации.
Управление Информация о состоянии объектов
управления собирается в центр для
принятия решения. Время сбора
информации порядка 1-5 секунд.
После оптимизационных расчетов
управляющие команды или уставки для
локальных регуляторов направляются на
объекты.
Обмен информацией между узлами модели
сети может производиться в оффлайн –
минуты, часы.
При непосредственном управлении в
зависимости от качества каналов связи
внешняя информация может поступать от
других узлов управления, или
восстанавливается косвенным путем по
измерениям на каждом объекта по
соответствующим моделям с временем
порядка мс.
Данные Действующие значения электрических
величин, коммутационные состояния
Векторные значения электрических величин
28. Пример архитектурных описаний энергокластера
«Эльгауголь»
09.10.2013 28
АрхитектураоборудованияИКТ-архитектураБизнес-архитектура
Подстанция 1 Подстанция 2
Интеграционная шина
Шина предприятия
ИЭУ ИЭУ
Шина станции
Шина процессаИнтерфейс
МИК SCADA
Оборудование
ИЭУ ИЭУ
Шина станции
Шина процессаИнтерфейс
МИК SCADA
Оборудование
ЦУС УЭР
АРМ МАС БД
ИЭУ ИЭУ
МИК SCADA
IEC 61850-8-1
IEC 61850-9-2
ИЭУ ИЭУ
МИК SCADA
IEC 61850-8-1
IEC 61850-9-2
ЦУС УЭР
АРМ МАС БД
IEC 61970
IEC 61970-1
IEC 61970-2
IEC 61970-301
TCP/IP
ACL
IIOP
АТС СО РДУ
Технологическая
нейтральность
Мультиагентное
управление
Стандартные
интерфейсы
Открытые
стандарты
Интересы
Заинтересованные
стороны
Совместимость
систем
Отв. за ПС
Связь интересов и
технологических
процессов
Генеральный
поставщикСетевая
компания
Потребитель
30. 09.10.2013 30
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
31. Реализованные рыночные механизмы управления
потреблением
09.10.2013 31
Германия
Франция
Великобритания
Программы, стимулирующие потребителей
электроэнергии к снижению потребления в
часы пиковых нагрузок и/или высоких цен на
рынке, применяются в США, многих странах
Европы и т.д. В рамках созданной коалиции
SEDC рассматривается опыт ряда стан,
внедряющих рыночные механизмы
управления потреблением и обсуждаются
вопросы договорных и неконтрактных
взаимоотношений
32. Бизнес-модель VPP по управлению распределенной
генерацией
09.10.2013 32
Ключевые функции оператора VPP:
Продажа агрегированной мощности
распределенной генерации
Эффекты VPP:
Обеспечение возможности
подключения новых потребителей в
«закрытых» центрах питания (без
больших инвестиционных затрат)
Повышение надежности
энергоснабжения потребителей
Снижение капитальных затрат
РОССЕТЕЙ на реконструкцию центров
питания
Доступ распределенной генерации на
рынок, дополнительный доход
владельцев распределенной
генерации
Оператор VPP*
Оператор рынка,
регулятор
РСК, ТСО
Потребитель
(с управляемой
нагрузкой)
Сетевая
мощность
- Передача э/э
- Условия для возможности
перераспределения мощности
- Резервирование
Потребитель
Мощность
Объекты
распределенной
генерации
+/- э/э
+/- мощность
Системные услуги
Мощность
Бизнес-модель VPP позволяет без существенных инвестиций в развитие сети
повысить эффективность использования сетевой мощности
Цель: Повышение эффективности
использования сетевой мощности
Механизм стимулирования
снижения нагрузки
потребителем
*Возможно создание 2 операторов VPP: коммерческого оператора для возможности выхода на ОРЭМ, и
технического оператора, осуществляющего технологическое управление объектами РГ
33. Бизнес-модель VPP по управлению потреблением
09.10.2013 33
Оператор VPP
Оператор рынка,
регулятор
РСК, ТСО
Потребитель
(с управляемой
нагрузкой)
Снижение
нагрузки
потребителя
- Передача э/э
- Условия для возможности
перераспределения сетевой мощности
- Резервирование
Потребитель
Сетевая
мощность
+/- э/э
+/- мощность
Механизм стимулирования
снижения нагрузки
потребителем
Бизнес-модель VPP может быть реализована на основе существующих
рынков э/э, мощности, системных услуг, на базе биржевой площадки, а
также посредством корпоративных программ
Цель: Уменьшение нагрузки на
объекты электросетевого комплекса
в пиковые часы
Ключевые функции оператора VPP:
Управление потреблением
Оператор рынка прав на сетевую мощность (в
перспективе)
Эффекты VPP:
Обеспечение возможности подключения
новых потребителей в «закрытых»
центрах питания (без больших
инвестиционных затрат)
Снижение капитальных затрат РОССЕТЕЙ
на реконструкцию центров питания
Доступ потребителей с управляемой
нагрузкой к ОРЭМ и получение
дополнительного дохода
Снижение потребления в часы пиковых
нагрузок и/или высоких цен на рынке
34. 09.10.2013 34
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
40. 09.10.2013 40
От вызовов к принципам создания новой энергосистемы
Вызовы
Требования (показатели качества)
Принципы (стратегии достижения показателей качества)
Шаблонные решения
Эталонная архитектура интеллектуальной энергосистемы
Необходимость эталонной архитектуры
Базовая эталонная архитектура
Расширения базовой эталонной архитектуры
Примеры архитектурных описаний
Пилотные проекты
От эталонной архитектуры к пилотным проектам
Управление напряжением и реактивной мощностью в энергокластере «Эльга-уголь»
Виртуальная электростанция (VPP)
Прототипы в пилотном проекте
Прототип мультиагентного 5-минутного рынка мощности
Прототип МАС управления напряжением и реактивной мощностью
Содержание
42. Агентная «социальная сеть»
09.10.2013 42
Самонастройка мониторинга состояния оборудования:
• Гибкие алгоритмы сбора и агрегирования данных
• Знания о структуре оборудования
• Передача выявленной важной информации, а не большого количества первичных
данных
• Обмен данными с соседями (p2p) для оценки собственной «нормальности»
44. Использование и развитие прототипа ПТК
09.10.2013 44
Использование:
• Сравнение централизованного и децентрализованного подходов к
управлению
• Использование решения для энергоснабжения ж/д объектов с тяговой
нагрузкой (БАМ, ТрансСиб)
• Перенос решения на другие кластеры, масштабирование системы
управления до ОЭС Востока
Реализация других функций управления:
• Оптимальное распределение активной мощности в нормальном режиме
(управление распределенной генерацией и управление спросом)
• Автоматическое конфигурирование сети – передача уставок управляемым
устройствам
• Интеллектуальное управления активами