Главная страница Случайная страница
КАТЕГОРИИ:
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Стадии и этапы создания АС 1 страница
|
|
2.1. Стадии и этапы создания АС в общем случае приведены в таблице.
| Этапы работ | |
| 1.Формирование требований к АС | 1.1. Обследование объекта и обоснование необходимости создания АС 1.2. Формирование требований пользователя к АС 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания) |
| 2. Разработка концепции АС | 2.1. Изучение объекта 2.2. Проведение необходимых научно-исследовательских работ 2.3 Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворявшего требованиям пользователя 2.4. Оформление отчета о выполненной работе |
| 3. Техническое задание | 3.1. Разработка и утверждение технического задания на создание АС |
| 4. Эскизный проект | 4.1. Разработка предварительных проектных решений по системе и ее частям 4.2. Разработка документации на АС и ее части |
| 5. Технический проект | 5.1. Разработка проектных решений по системе и ее частям 5.2. Разработка документации на АС и ее части 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации |
| 6. Рабочая документация | 6.1. Разработка рабочей документации на систему и ее части 6.2 Разработка или адаптация программ |
| 7. Ввод в действие | 7.1. Подготовка объекта автоматизации к вводу АС в действие 7.2. Подготовка персонала 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 7.4 Строительно-монтажные работы 7.5. Пусконаладочные работы 7.6. Проведение предварительных испытаний 7.7. Проведение опытной эксплуатации 7.8. Проведение приемочных испытаний |
| 8. Сопровождение АС | 8.1. Выполнение работ в соответствии с гарантийными обязательствами 8.2. Послегарантийное обслуживание |
2.2. Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.
Допускается исключать стадию " Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии " Технический проект" и " Рабочая документация" в одну стадию " Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
3.2.2 ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
Общие положения
1.1. Техническое задание на автоматизированную систему (ТЗ на АС) является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.
1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.
Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.
1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.
1.4. Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.
1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.
1.6. В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система.
1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с...».
Состав и содержание
2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:
1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию системы;
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.
В ТЗ на АС могут включаться приложения.
2.2. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ.
В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.
2.3. В разделе «Общие сведения» указывают:
1) полное наименование системы и ее условное обозначение;
2) шифр темы или шифр (номер) договора;
3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
5) плановые сроки начала и окончания работы по созданию системы;
6) сведения об источниках и порядке финансирования работ;
7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:
1) назначение системы;
2) цели создания системы.
2.4.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.
Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.
2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
2.5. В разделе «Характеристики объекта автоматизации» приводят:
1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.
2.6. Раздел «Требования к системе» состоит из следующих подразделов:
1) требования к системе в целом;
2) требования к функциям (задачам), выполняемым системой;
3) требования к видам обеспечения.
Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.
2.6.1. В подразделе «Требования к системе в целом» указывают:
требования к структуре и функционированию системы;
требования к численности и квалификации персонала системы и режиму его работы;
показатели назначения;
требования к надежности;
требования безопасности;
требования к эргономике и технической эстетике;
требования к транспортабельности для подвижных АС;
требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
требования к защите информации от несанкционированного доступа;
требования по сохранности информации при авариях;
требования к защите от влияния внешних воздействий;
требования к патентной чистоте;
требования по стандартизации и унификации;
дополнительные требования.
3.3 Концепция открытых систем. Основные понятия
Рассмотрим теперь концепцию открытых систем, которая относится к важнейшим глобальным концепциям развития области ИТ. Можно считать, что ее разработка открыла новый этап в процессе стандартизации ИТ, характеризующийся системным подходом к разработке стандартов. В данной концепции обосновывается экономическая целесообразность перехода к открытым системам ИТ, т.е. к системам, удовлетворяющим свойствам открытости. Практическое воплощение данной концепции обеспечивает оптимальные условия для инвестиций в ИТ.
Под основными свойствами открытости понимаются:
· переносимость и многократность использования программного обеспечения, данных и опыта людей;
· интероперабельность, т. е. возможность взаимодействия компонентов распределенной системы посредством обмена
· масштабируемость как свойство сохранения работоспособности системы ИТ в условиях варьирования значений параметров, определяющих технические и ресурсные характеристики системы и/или поддерживающей среды.
Более полные определения этих понятий мы рассмотрим ниже.
Открытость систем достигается на основе стандартизации их поведения, наблюдаемого на границах систем или их интерфейсах. Таким образом, под открытыми системами можно понимать системы, обладающие стандартизованными интерфейсами, и решение проблемы открытости систем основывается на стандартизации интерфейсов систем и протоколов взаимодействия между их компонентами.
Впервые концепция открытых систем была реализована в телекоммуникационных системах. В начале 80-х годов ряд международных организаций по стандартизации разработали модель, которая сыграла значительную роль в развитии сетей. Эта модель была названа моделью взаимодействия открытых систем или моделью OSI (Open System Interconnection). В телекоммуникационных и сетевых системах модель OSI определяет различные уровни взаимодействия систем, дает им стандартные имена и указывает, какие функции должен выполнять каждый уровень. Модель OSI была разработана на основании практического опыта, полученного при создании компьютерных сетей, в основном глобальных, в 70-е годы. Полное описание этой модели занимает более 1000 страниц текста. В модели OSI для сетевых и телекоммуникационных систем средства взаимодействия делятся на семь уровней: прикладной, представительный, сеансовый, транспортный, сетевой, канальный и физический (рисунок 3.1). Каждый уровень имеет дело только с одним аспектом взаимодействия сетевых устройств.
Модель OSI описывает только системные средства взаимодействия, реализуемые операционной системой, системными утилитами, системными аппаратными средствами. Модель не включает средства взаимодействия приложений конечных пользователей.
| Полезная информация |
| Служебная информация |
| Компьютер 1 |
| Компьютер 2 |
| Физический уровень |
| Интерфейсы |
| Прикладной уровень Представительный уровень Сеансовый уровень Транспортный уровень Сетевой уровень Канальный уровень |
| Процесс В |
Рисунок 3.1. Модель взаимодействия открытых систем OSI
Собственные протоколы взаимодействия приложения реализуют, обращаясь к системным средствам. Поэтому необходимо различать уровень взаимодействия приложений и прикладной уровень. Приложение может взять на себя функции некоторых верхних уровней модели OSI. Более подробно семиуровневая модель взаимодействия сетевых устройств будет рассмотрена в специальном курсе «Телекоммуникационные сети и системы».
Возвращаясь к общей концепции открытых систем, отметим, что методологическую основу этой концепции составляют:
· концептуальный базис и принципы построения открытых систем,
· эталонная модель окружений открытых систем (RM OSE – Reference Model of Open Systems Environment),
· эталонная модель взаимосвязи открытых систем (RM OSI – Reference Model of Open Systems Interconnection), аппарат профилирования ИТ, предназначенный для конструирования открытых систем в пространстве стандартизованных решений,
· концепция тестирования конформности систем ИТ исходным стандартам и профилям,
· таксономия профилей.
3.3.1 Методологическая основа концепции открытых систем ISO
В соответствии с документами международной организации по стандартизации (International Standard Organization – ISO), определяющими методологическую основу концепции открытых систем, являются следующие [2].
1.Технический отчет ISO/IEC TR 10000 Framework and taxonomy of International Standardized Profiles (Основы и таксономия международных стандартизованных профилей) в трех частях, включая:
Часть 1. General Principles and Documentation Framework (Общие принципы и основы документирования).
Часть 2. Principles and Taxonomy for OSI Profiles (Принципы и таксономия профилей взаимосвязи открытых систем).
Часть 3. Principles and Taxonomy for Open System Environment Profiles (Принципы и таксономия профилей окружений открытых систем).
Эталонная модель окружения (среды) открытых систем (RM OSE) - ISO/IEC DTR 14252, Portable Operating System Interface for Computer Environments - POSIX. (IEEE, PI003.0, Draft Guide to the POSIX Open System Environment).
Эталонная модель взаимосвязи открытых систем (RM OSI) – ISO 7498: 1996, Information processing systems - Open Systems Interconnection - Basic Reference Model [ITU-Т Rec. X.200].
Опираясь на эти документы, рассмотрим базовые понятия открытых систем, иерархическую модель пространства спецификаций ИТ (стандартов и профилей).
Анализ методологических основ открытых систем начнем с определения наиболее важных понятий данной концепции.
1. Стандарт (по определению ISO). Технический стандарт или другой документ, доступный и опубликованный, коллективно разработанный или согласованный и общепринятый в интересах тех, кто им пользуется, основанный на интеграции результатов науки, технологии, опыта, способствующий повышению общественного блага и принятый организациями, полномочными на национальном, региональном и международном уровнях.
2. Базовый стандарт (base standard), также иногда используются термины формальный стандарт или стандарт de-ure. Международный стандарт, принятый международной организацией по стандартизации ISO, или рекомендация международного союза по телекоммуникациям ITU-T (International Telecommunication Union - Telecommunication).
3. Эталонная модель (Reference Model). Структурированная коллекция понятий и их взаимосвязей некоторой предметной области, определяющая структуру данной области и описанная достаточно общими средствами. По существу эталонная модель является формой метазнаний, определяющих принципиальную декомпозицию (архитектурную спецификацию) конкретной предметной области.
4. Система ИТ или ИТ-система (IT system ) (или по тексту просто система, если это не вызывает двусмысленности). Совокупность ресурсов информационных технологий, предоставляющая сервис (услуги) на одном или большем числе интерфейсов в соответствии с заданными спецификациями. В стандартах POSIX аналогичным понятию системы ИТ является понятие прикладной платформы (application platform).
5. OSE (Open Systems Environment - Окружение или среда открытых систем). Исчерпывающий набор интерфейсов, сервисов, форматов, а также пользовательских аспектов, позволяющих достичь целей интероперабельности и/или переносимости приложений (про грамм), данных, людей на основе применения базовых стандартов и профилей ИТ. В эталонной модели RM OSE под открытой системой понимается система, реализующая OSE, под которым понимается окружение, удовлетворяющее стандартам или от крытым спецификациям.
6. Переносимость (portability). Свойство системы, характеризующее легкость переноса прикладного программного обеспечения и данных (а также пользователей) с одной системы ИТ на другую.
7. Интероперабельность (interoperability). Способность систем обмениваться информацией друг с другом и совместно использовать информацию, которой они обмениваются.
8. Масштабируемость (scalability). Свойство системы, позволяющее ей работать в широком диапазоне параметров, определяющих технические и ресурсные характеристики системы и/или поддерживающей среды (примерами таких характеристик могут служить: число процессоров, число узлов сети, максимальное число обслуживаемых пользователей, количество обрабатываемых транзакций).
9. Общедоступные спецификации (Publicly Available Specifications PAS). Это хорошо отработанные спецификации, как правило, являющиеся стандартами де-факто, которые принимаются ISO для проведения специальных процедур по их стандартизации на международном уровне. Важным требованиям к PAS является то, что их сопровождение осуществляется известными профессиональными организациями посредством прозрачного публичного процесса, основанного на консенсусе. Близким по смыслу к понятию PAS является понятие открытых спецификаций, определенное в эталонной модели RM OSE следующим образом: " открытыми спецификациями являются спецификации, поддерживаемые организациями, которые используют открытый, общедоступный, основанный на консенсусе процесс сопровождения спецификаций для адаптации их к новым технологиям и пользовательским требованиям". Примерами PAS могут служить спецификации DCE, разработанные организацией OSF.
10. Профиль (Profile) - набор, состоящий из одного или большего числа стандартизованных спецификаций (базовых стандартов и/или международных стандартизованных профилей) и определяющий выбор из этих спецификаций необходимых для реализации конкретной прикладной функции классов сервиса, опций, параметров, тестовых наборов. Таким образом, профиль задает некоторую функциональность, необходимую для выполнения конкретной прикладной задачи, агрегируя избирательным образом функциональные возможности стандартизованных спецификаций (стандартов или ISPs).
11. Международный стандартизованный профиль (International Standardized Profile - ISP). Официально принятый и согласованный на международном уровне документ, описывающий один или несколько профилей. (В случае множественного числа ISP будем использовать обозначение ISPs). В эталонной модели RM OSE используется близкое к ISP понятие стандартизованного профиля — баллотированного, формального, гармонизированного документа, описывающего профиль.
12. OSE-профиль (OSE-profile). Профиль, специфицирующий полностью или частично поведение системы ИТ, наблюдаемое на одном или большем числе ее интерфейсах.
13. OSI-профиль (OSI-profile). Профиль, составленный из базовых спецификаций, соответствующих модели RM OSI, возможно дополненных базовыми стандартами и/или профилями для представления обмениваемых данных и их форматов (так называемыми F-профилями).
Таким образом, OSI-профили определяют поведение систем, проявляемое только на их коммуникационных интерфейсах, по строенных с помощью стандартов, входящих в архитектуры OSI.
14. API-профиль (API-profile- Application Program Interface). Профиль, определяющий конкретную комбинацию базовых спецификаций прикладного пользовательского интерфейса в соответствии с моделью RM OSE, возможно дополненных базовыми стандартами и/или профилями для представления данных и их форматов (F-профилями).
15. Таксономия (Taxonomy). Классификационная схема, применяемая для однозначной идентификации профилей или наборов про филей.
3.3.2 Примеры профилей
С целью пояснения введенных понятий рассмотрим иллюстративные примеры, в которых будем использовать различные типы профилей для определения функциональности систем ИТ [2].
Пример 1. В данном примере зададимся целью определить профили основных функциональных компонентов корпоративной информационной технологии некоторой организации, которая хотела бы обеспечить переносимость разрабатываемых ей SQL-приложений (как серверной, так и клиентских частей), написанных с использованием языков C++ и SQL. При этом для определенности будем предполагать, что сетевая инфраструктура данной организации основана на использовании локальной оптоволоконной сети FDDI (смотри рисунок 3.2).
Для обеспечения сформулированных выше целей открытости корпоративная технология должна строиться из систем, поведение которых на своих интерфейсах соответствует стандартам. В частности, в данном случае задача состоит в том, чтобы построить два OSE-профиля:
один, специфицирующий требования к интерфейсам клиентских систем,
другой - к интерфейсам сервера баз данных.
Рисунок 3.2 Пример корпоративной информационной системы
Профиль клиентской системы обозначим Рс. Он будет включать спецификации как минимум двух классов интерфейсов, а именно, интерфейса API, определяющего взаимодействие клиентской системы с прикладной программой (Application program), а также коммуникационного интерфейса, определяющего состав протоколов сетевого взаимодействия между клиентскими и серверными системами.
Для коммуникационного интерфейса можно выбрать протокол прикладного уровня RDA (ISO 9579), используемый, в частности, для реализации распределенных SQL-приложений с архитектурой клиент-сервер над стеком протоколов модели RM OSI. Для большей гибкости решения разобьем стек протоколов модели RM OSI на две группы - протоколы верхних трех уровней, которые обозначим OSI Stack (7-5), и протоколы транспортной системы, обеспечивающие транспортные услуги OSI в режиме с соединением.
В справочнике международных стандартизованных профилей существует профиль, описывающий набор протоколов для реализации передачи данных по транспортному протоколу OSI через локальную сеть FDDI. Данный профиль имеет наименование ТС54. Он включает ссылки на стандарт транспортного протокола OSI, стандарт протокола сетевого уровня (Х.25) вместе с дополнениями, адаптирующими этот протокол для использования в локальных сетях, а также ссылки на стандарты протоколов нижних уровней, определяющих функционирование сети FDDI. Профиль ТС54 является типичным примером OSI-профиля, так как определяет только функции сетевого взаимодействия, определенные стандартными протоколами, разработанными в соответствии с моделью RM OSI.
Таким образом, описание коммуникационного интерфейса в профиле Рс будет включать ссылки на следующие спецификации:
· стандарт протокола DRA,
· стандарты протоколов верхних уровней модели RM OSI (OS Stack (7-5)) профиль ТС54.
В состав спецификаций API следует включить стандарты языков C++ и SQL (обозначим их как Std «C++» и Std «SQL» соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Таким образом, описание интерфейса API в профиле Рс включает ссылки на следующие спецификации:
· Std «C++»
· Std «SQL»
· интерфейс RDA-клиента.
В профиль Рс могут быть включены спецификации и других классов интерфейсов, как, например, графического пользовательского интерфейса. И в профиль Рс пришлось бы включать такие ссылки, если бы одним из исходных требований к разрабатываемой системе было требование обеспечения легкости перевода пользователей с одной компьютерной платформы на другую.
Профиль серверной части, обозначим его Ps, будет содержать идентичный с профилем Рс коммуникационный интерфейс (иначе клиентские и серверные системы не смогли бы взаимодействовать). Интерфейс API профиля Ps будет почти идентичным соответствующему интерфейсу профиля Рс, за исключением различий в программных интерфейсах для сервиса RDA в клиентской и сервисных системах. Однако для простоты примера не будем заострять внимание на этих различиях.
Пример 2. В этом примере рассмотрим профили, разработанные с целью классификации и описания функциональности оконечных систем для различных технологий обработки сообщений. Такие профили предназначены для разработчиков оконечных систем обработки сообщений, например, для разработчиков информационных приборов (information appliances), предоставляющих пользователям сервис электронной почты.
Стандартизации сервисов и принципов функционирования систем обработки сообщений (Message Handling System - MHS) посвящена серия рекомендаций ITU-T X.400 (в эквивалентном этим рекомендациям стандарте ISO 10021 системы данного класса называются системами обмена текстовыми сообщениями (Message-oriented Text Interchange Systems - MOTIS)). Кроме этого, серия F.400 рассматривает вопросы использования для передачи сообщений систем телематики (телекс, телетекст, видеотекст, факс) и систем физической доставки сообщений (почта, курьерская доставка), а также использование систем передачи сообщений для передачи электронных данных.
Большое число и функциональная сложность этих стандартов, а также многообразие возможных реализаций почтовых систем делают актуальным систематизацию возможных решений в этой области на основе разработки системы профилей.
Прежде, чем перейти к описанию профилей для классов систем MHS, рассмотрим функциональную модель системы обработки сообщений, а также принципы ее работы. Данная модель иллюстрируется на приведенном ниже рисунке 3.3.
Рисунок 3.3. Функциональная модель системы обработки сообщений (MHS):
На рисунке обозначено:
MTS - Message Transfer System - система передачи сообщений;
МТА - Message Transfer Agent - агент системы передачи сообщений;
MS — Message Store - система хранения сообщений;
UA — User Agent — агент пользователя;
PDAU - Physical Delivery Access Unit - блок доступа к услугам физической доставки;
AUs - Access Units - блоки доступа к услугам систем телематики;
user – пользователь.
Система обработки сообщений предоставляет пользователям возможность обмениваться сообщениями на основе метода промежуточного хранения сообщений (Store-and-forward - запомни-передай). Сообщения, отправляемые пользователем-отправителем (originator) через соответствующий ему прикладной процесс UA, передаются системой передачи сообщений MTS (являющейся составной частью системы обработки сообщений MHS) одному или нескольким пользователям -получателям (recipient). Все функции в MHS выполняются активными сущностями (прикладными процессами OSI), какими являются МТА, MS, UA, AU.
В частности:
· агенты МТА обеспечивают передачу между узлами системы MTS накопленных в них сообщений, а также предоставление сервиса MTS своим пользователям (агентам UA и системам хранения MS);
· системы хранения сообщений MS хранят полученные от MTS сообщения и предоставляют возможность своим пользователям осуществлять поиск полученных сообщений и манипулирование ими;
· агенты UA обеспечивают пользователям доступ к сервисам MHS;
· блоки доступа AU реализуют подключение к системе передачи MTS различных служб телематики и служб физической доставки почты.
Для описанной системы может быть применена система профилей X.400, которая содержит описание сервисов рассмотренных выше функциональных компонентов системы MHS и протоколов взаимодействия между ними. Это описание содержит несколько сотен страниц и охватывает три сферы применения систем MHS, а именно: