Расчетная частьРассмотрим наиболее важные для систем моделирования свойства, которые могут быть оценены количественно: Объем программы и моделей Быстродействие системы Надежность. Объем зависит от состояния системы и измеряется в Мегабайтах (Мб): 1Мб = 220 = 1 048 576 байт. Рассмотрим 3 возможных состояния системы моделирования: Хранение на жестком диске в готовом к запуску состоянии. Хранение на любом носителе в виде архива. Рабочее состояние. При хранении на жестком диске система включает исполняемый (exe) файл, объем которого постоянен, файлы библиотек (dll), файлы конфигурации (cfg), настройки (ini) и другие служебные файлы. Суммарный объем этих файлов для AnylogicTM не превышает 100 Мб. Размер хранимых файлов с моделями зависит от их сложности и для рассмотренных примеров моделей составляет от 1500 до 155000 байт. Для современных компьютеров такой объем информации очень мал. При хранении программ моделирования и множества моделей в виде архива достигается задача сохранения множества файлов и папок в одном файле, так как задача экономии места на жестком диске здесь не стоит. Для записи на гибкие диски эта процедура необходима, так как их объем всего 1.44 Мб. При архивации большинство моделей помещаются на 1 (в крайнем случае, на 2) дискетах. Объем программ моделирования на стадии выполнения определяется структурой переменных, использованных при программировании и размерностью исполняемой модели. Для рассмотренного пакета необходимый раздел оперативной памяти составляет не более нескольких десятков Мбайт. Одно из важных направлений развития методики моделирования – сохранение полного протокола сеансов – ставит серьезную задачу по минимизации его объема. Если сохранять протокол полностью – как последовательность всех состояний, то объем создаваемого файла протокола можно оценить так: пусть количество мест в модели равно N, формат количества объектов в месте – 4 байта, модельное время – также имеет формат 4 байта (от 0 до 231), ^ К – среднее количество шагов моделирования до остановки прогона, М – число повторов прогона модели с 0-го времени. Тогда максимальный объем (в байтах) файла протокола составит:4N × 4К × 4М Если число мест в модели 100, среднее число шагов до остановки (или тупика) 1000000 (106), число прогонов – также 1000000 (106), объем протокола составит 256×1014, т.е. 25 миллионов Мбайт. Взятые в этом примеры числа не слишком велики при исследовании отказоустойчивости многих критических с точки зрения безопасности систем управления. Иногда при разработке таких систем в ТЗ требуется обеспечить надежность на уровне «девять девяток» или 0.999999999. Ясно, что число испытаний и максимальную их длительность надо увеличить до предела, т.е. до 231. Тогда объем протокола составит максимум 100×262 или около 1015Мб. Столь фантастический объем превосходит общую емкость накопителей компьютеров всей планеты. Чтобы решить проблему огромного объема протокола, надо выяснить, зачем и как его использовать по завершению сеанса моделирования и возможности сжатия информации при записи в протокол. Пошаговое сохранение состояния модели нужно лишь в том случае, когда произошло редкое событие, соответствующее перегрузке или отказу системы. Тогда можно однозначно восстановить цепочку событий, приведших к этому и скорректировать алгоритм поведения системы для защиты от такой ситуации. Все остальные данные в протоколе не нужны (они отражаются в суммарных итогах моделирования и занимают не более 100×(N + Р) байт, где Р – количество тактов). Таким образом, достаточно хранить только протокол текущего прогона модели (пока он не закончился, возможны любые ситуации). Здесь целесообразно применить алгоритм двойной буферизации: пока идет очередной прогон с формированием своего файла-протокола, протокол предыдущего прогона можно анализировать различными программными средствами, в том числе и внешними по отношению к пакету моделирования. На этот анализ будет достаточно времени, что будет показано при оценке быстродействия систем моделирования. После завершения очередного прогона указатель позиции для записи файла-протокола «перекидывается» на начало освободившегося файла (второй буфер). Быстродействие системы определяется техническими характеристиками ПК, главные из которых в данном случае – это быстродействие процессора и скорость жесткого диска (HDD). Объем оперативной памяти (RAM) не так существенен, вполне достаточно на уровне 256 Мб. Оценим время процессора ^ T1, затрачиваемое на один такт работы модели: T1 = P×D×S×t, где P – число переходов (пусть для примера равно 100), D – среднее число входящих + исходящих коннекторов (пусть равно 4), S – среднее число тактов процессора на реализацию простого цикла программы моделирования (зависит от эффективности компилятора Java и опыта программиста, минимальное значение достигается при использовании ассемблера, примем значение 100), t – время такта процессора, около 1нс = 10-9с. В нашем примере получится T1 = 100×4×10023110-9с = 4×10-5с = 40мс. Учитывая, что количество шагов моделирования может достигать 231, получим оценку времени одного прогона модели: 231×4×10-5с = 80000с, т.е. почти сутки! Получаем еще более удручающий результат, чем при записи протокола, означающий либо непригодность как инструмента исследования отказоустойчивости, либо необходимость оптимизации программ и структур данных пакетов моделирования. Выход состоит в следующем: использовать для промышленных систем моделирования суперкомпьютеры, имеющие показатели производительности на 3-4 порядка выше обычных ПК Эти весьма дорогостоящие меры позволят сократить максимум времени одного прогона модели до 1с. Но требование «девять девяток» остается недостижимым (более 3 лет испытаний на суперкомпьютере производительности 1Тфлоп). Вывод – это требование в ТЗ на разработку сложной системы при современном этапе развития вычислительной техники некорректно. С другой стороны, темпы развития ВТ таковы, что через три года суперкомпьютеры с производительностью 1000Тфлоп станут рядовым явлением, а на них полный цикл испытаний по критерию 9×9 займет не более суток.Надежность данной системы является ключевым параметром, в противном случае результаты моделирования будут недостоверны. Для этого необходимо проверить адекватность моделей, т.е. то, что они достаточно точно отражают существенные для конкретных исследований свойства реальных систем. Критерием является соответствие результатов моделирования реальному поведению этих систем. В данном проекте рассмотрены такие модели: терминал аэропорта, перекресток, т.е. достаточно сложные по своему поведению системы, объективные данные о работе которых должны быть тестом пригодности пакетов моделирования. Другие параметры надежности, связанные с безотказностью работы аппаратуры ПК и его ОС не так существенны: потеря данных по одному или нескольким прогонам модели на фоне миллионов испытаний не критична. Другое дело – надежное сохранение результатов испытаний в базе данных. Но это уже функция системного обслуживания ПК и не входит в задачи пакетов моделирования. Здесь - стандартная ситуация. Источниками отказов системы моделирования могут быть: Отказы аппаратуры ПК (особенно жесткого диска) Отказы системного ПО (особенно MS Windows) Заражение компьютерными вирусами Потеря данных из-за неопытности пользователя Внутренние ошибки системы. Методы защиты общеизвестны: Создание архивных копий Установка 2 или более ОС на один ПК Использование антивирусных программ и своевременное обновление антивирусных баз.О выявлении внутренних ошибок уже было сказано, остальные источники отказов устраняются 3 стандартными методами. Таким образом, надежность работы системы моделирования определяется как опытом работы ее пользователей с ПК, так и степенью ее отлаженности на моделях реальных систем. Поэтому новые пакеты моделирования целесообразно «обкатывать» в учебном процессе, когда она испытывается сотнями пользователей.