Аналитические и имитационные модели 2 страница

Каждая стадия проектирования работ может быть описана в терминах проектных процедур и операций с учетом их логических связей. Весь процесс проектирования после этого становится логически увязанной системой стадий, процедур и операций. Эту систему называют обобщенным алгоритмом проектирования.

Для каждой степени детализации описания объекта (иначе говоря, для каждого уровня иерархической структуры проектируемого объекта: объект (0-уровень) —> обеспечивающие подсистемы (1 уровень) —> узлы (2 уровень) —> .......—> элементы (последний к-ый уровень)) выполняется следующая последовательность проектных операций:

1) формализация целей проектной задачи,

2) анализ исходных данных,

3) выработка предварительных предложений о средствах достижения целей (декомпозиция объекта проектирования на составляющие части или синтез структуры),

4) моделирование выбранных классов или типов объектов проектирования в виде функциональных соотношений или других математических моделей, о которых речь пойдет далее; ограничений, и функционалов качества.

5) выработка вариантов проектных решений на основе анализа моделей,

6) испытание и структурное согласование предварительных проектных решений,

7) принятие окончательных проектных решений,

8) документирование результатов проектирования как законченного фрагмента проекта.

Стратегия принятия окончательного проектного решения для разных проектных процедур может быть различной, но особое место среди них занимает выработка и принятие оптимального решения. Проектные решения называют оптимальными, если они обеспечивают наивыгоднейшие в каком-то смысле свойства объектов проектирования, т.е. проектируемые решения отыскиваются в этом случае из условия максимума или минимума функционалов качества.

Важно отметить, что необходимость формализации для автоматизации проектной процедуры с необходимостью приводят к созданию соответствующего проблемно-ориентированного языка со своей терминологией и символикой.

Сложность алгоритма проектирования, с одной стороны, и наличие современных технических средств обработки информации, с другой стороны, предопределяют целесообразность и возможность автоматизированного проектирования.

Возможности автоматизации велики в таких трудоемких проектных операциях, как хранение и выбор исходных данных, математическое описание объектов проектирования, реализация алгоритмов поиска проектных решений, коррекция исходных данных и принятых решений по результатам испытаний, документирование, в том числе графическое, промежуточных и итоговых результатов. Без проектировщика не обойтись при постановке проектных задач, определении концепций о средствах достижения целей, принятии окончательных решений на стыках проектных процедур и стадий. Однако на настоящем этапе наличие интеллектуальных систем может значительно облегчить проектировщику решение и этих задач.

Таким образом, развитые САПР, обеспечивающие высокую степень автоматизации, должны представлять проектировщику выполнение таких функций как работа с базами развивающихся знаний в той или иной области проектирования; формализованное описание объектов проектирования в виде их математических моделей; оценка точности и прогноза состояния моделей; генерация вариантов и поиска оптимальных проектных решений; информационное обеспечение процесса моделирования и принятия решений; документирование этапов проектирования; эффективный диалог проектировщика с системой на основе применения проблемно-ориентированных языков программирования и проектирования. В такой среде проектировщик должен максимально типизировать и унифицировать проектные решения, разрабатывать экономичные языковые средства диалогового проектирования, определять рациональные объемы баз знаний и структуру информации в них; разрабатывать формы документирования, допускающие эффективную математическую реализацию.

Итак, для получения максимального эффекта автоматизации проектирования САПР должна удовлетворять запросы проектировщика; проектировщик обязан в полной мере учитывать специфику и реальные возможности системы.

3.3. Виды обеспечения САПР. Системные среды САПР

Средства автоматизации проектирования структурируются по видам обеспечения: математическое обеспечение, программное обеспечение, техническое обеспечение, информационное обеспечение, организационное обеспечение, методическое обеспечение.

Математическое обеспечение - это совокупность математических методов, математических моделей и алгоритмов проектирования, необходимых для выполнения автоматизированного проектирования. Программное обеспечение - совокупность машинных программ, необходимых для выполнения автоматизированного проектирования. Среди этой совокупности выделяются программы для организации функционирования технических средств, т.е. для планирования и управления вычислительным процессом, распределения вычислительных ресурсов между многими пользователями. Эта часть представляет общесистемное ПО. Общесистемное ПО создается для многих приложений и не отражает специфику САПР. Эта специфика находит отражение в базовом и прикладном ПО. В базовое ПО входят программы, обеспечивающие функционирование прикладных программ. В прикладном ПО реализуется математическое обеспечение для непосредственного выполнения проектирования процедур. Прикладное ПО реализуется в виде ППП. Техническое обеспечение представляет совокупность технических средств, предназначенных для выполнения автоматизированного проектирования. ТО делится на группы средств программной обработки данных, подготовки и ввода данных, отображения и документирования, архива проектируемых решений, передачи данных. Средства программной обработки данных представлены процессорами и запоминающими устройствами, в которых реализуется программная обработка данных и программное управление с вычислениями. Средства подготовки, ввода отображения и документирования данных служит для общения человека с ЭВМ. Средства проектирования решений представлены внешними запоминающими устройствами. Средства передачи данных используются для организации связей между территориально удаленными ЭВМ и терминалами (оконечными устройствами).

Информационное описание объекта проектирования реализуется при автоматизации проектирования в информационном обеспечении САПР. Информация об объектах проектирования представляется в виде документов на машинных носителях, содержащих сведения справочного характера о материалах, комплектующих изделиях, типовых проектных решениях, параметров элементов, сведения о состоянии текущих разработок в виде промежуточных и окончательных проектных решений, структур проектных объектов и т.п. Основная составная часть ИО САПР - банк данных, состоящий из БД и СУБД.

БД - сами данные, находящиеся на машинных носителях информации, т.е. в запоминающих устройствах ЭВМ, и структурированные в соответствии с принятыми в БД правилами. СУБД - совокупность программных средств, обеспечивающих функционирование банка данных. С помощью СУБД производится запись данных в банк, их выборка по запросам пользователей и прикладных программ, обеспечивается защита данных от искажений и от несанкционированного доступа и т.п.

Лингвистическое обеспечение - совокупность языков проектирования, предназначенных для описания процессов автоматизированного проектирования и проектных решений. Это язык общения проектировщика с ЭВМ. В развитых САПР таких языков может быть несколько, причем каждый из них основывается на правилах формализации естественного языка и использует методы сжатия и развертывания текста.

Методическое обеспечение составляют документы, регламентирующие состав, правила отбора и эксплуатации средств автоматизированного проектирования. Допускается и более широкая трактовка понятия методического обеспечения, при котором под ним понимается совокупность математического, лингвистического обеспечения и названных документов, реализующих правила использования средств проектирования.

Организационное обеспечение включает положения, инструкции, приказы, штатные расписания, квалификационные требования и другие документы, регламентирующие организационную структуру подразделений проектных организаций и взаимодействие подразделений с комплексом средств автоматизированного проектирования.

Каждая подсистема строится на основе различных, но взаимосвязанных средств автоматизации. Эти средства можно условно разбить опять же на семь видов обеспечения САПР, а именно: математическое, программное, информационное, техническое, лингвистическое, методическое и организационное.

Основу математического обеспечения составляют алгоритмы, по которым разрабатывается программное обеспечение САПР. Элементы математического обеспечения в САПР чрезвычайно разнообразны. Они зависят, конечно, от особенностей объекта проектирования и могут быть как в достаточной мере инвариантными, так и весьма специфическими. Скажем, все системы, проектирующие трехмерные объекты, должны использовать методы построения и описания такого рода объектов, т.е. математический аппарат вычислительной геометрии, который в известной мере можно считать инвариантным. При решении оптимизационных задач используются различные методы поиска экстремумов, многие из которых применяются только в конкретной предметной области.

Программное обеспечение подразделяют на общесистемное и специальное. Разделение вполне понятное и особых комментариев не требует. Ясно, что операционные системы относятся к первому виду ПО, а , скажем, программное обеспечение для прогнозирования погоды в Екатеринбурге - к очень специальному.

В общесистемном программном обеспечение выделяют, в свою очередь, такой компонент, как базовое программное обеспечение, т.е. такое, которое не является объектом разработки при создании программного обеспечения, например, какая-либо СУБД.

Информационное обеспечение представляет собой совокупность данных, размещенных на различных носителях информации, которые используются для проектирования. Это могут быть различные справочники, таблицы, промежуточные проектные решения, параметры проектируемого изделия и т.п., в общем все, что угодно. Иногда совокупность такого рода данных называют еще информационным фондом. Формы организации информационного обеспечения в компьютере могут быть различны, например: файлы или библиотеки. Библиотечная форма организации данных широко применяется в отечественных ЭВМ типа ЕС или СМ. Наиболее естественным и распространенным способом ведения информационного фонда в настоящее время является формирование баз данных, доступ к которым осуществляется различными системами управления базами данных.

Остановимся более подробно на проблемах выбора технических средств САПР.

Как мы уже отмечали ранее, к техническим средствам САПР относятся не только компьютеры, но и различные технические устройства, приборы, периферийные средства, которые необходимы для обеспечения процесса проектирования. К периферийным техническим средствам относятся, в частности, графопостроители и перфораторы (устройства вывода информации на перфоленту). Причем, если для функционирования наиболее распространенных графопостроителей, как правило, в базовом программном обеспечении САПР имеются необходимые программные средства (драйверы), то для стыковки, скажем, IBM-совместимых персональных компьютеров и широко распространенных на предприятиях перфораторов типа ПЛ150М необходимы уже дополнительные технические устройства (адаптеры).

Остановимся несколько подробнее на компьютерах, применяемых в САПР.

Очевидно, что подавляющая часть компьютеров, используемых в настоящее время в нашей стране для автоматизации проектирования(впрочем, и не только для этих целей) представляют собой IBM-совместимые персональные компьютеры. Надо отметить, что термин “IBM-совместимые” сейчас используется реже, больше говорят о “платформах”, аппаратной или программной. Для персональных компьютеров аппаратная платформа определяется типом процессора (часто говорят: “интелловская“ платформа), а программная - типом операционной системы (MS DOS или MS WINDOWS). Впрочем, терминология здесь очень не устоявшаяся. И не всегда люди, использующие один термин, имеют в виду одно и то же. Характерным примером является термин “рабочая станция”. Если вы говорите со специалистом по сетевым технологиям, то под рабочей станцией он обычно понимает персональный компьютер, выполняющий функции “клиента” в технологии “клиент-сервер”. Вместе с тем, этот термин уже довольно давно используется для обозначения вполне определенного класса компьютеров, выпускаемых ,как правило, на основе так называемых RISC-процессоров рядом известных западных производителей. Именно этот класс компьютеров в отличие от персональных чаще всего применяется для решения задач автоматизации проектирования на крупных и средних предприятиях большинства развитых стран Запада. Рабочие станции, в частности, производят такие знаменитые компьютерные фирмы, как HEWLETT PACKARD(HP), IBM, SILICON GRAPHICS(SGI), SUN Microsystem, DIGITAL(DEC) и ряд других. Как правило, рабочие станции работают на программной платформе UNIX, хотя большинство фирм-производителей предлагают и собственные специфические операционные системы. Нужно отметить, что версии OC UNIX для разных типов рабочих станций также имеют свою специфику.

Можно выделить две основные особенности рабочих станций как типа компьютеров:

- высокая производительность (наряду с другими техническими характеристиками) и использование RISC-процессоров;

- повышенные возможности для решения задач машинной графики.

Эти особенности и определили привлекательность рабочих станций для САПР, в которых решение сложных геометрических и графических задач занимает важное место. Существенная часть такого рода задач решается рабочими станциями на аппаратном уровне с помощью специализированных процессоров, что как раз и обеспечивает высокую эффективность и производительность станций в сравнении с “персоналками”. Но, как говорится, “за все надо платить”. В данном случае платить приходится непосредственно деньгами и очень немалыми. Стоимость рабочих станций может достигать, естественно, в зависимости от конфигурации, нескольких десятков тысяч долларов. Именно поэтому в нашей стране предпочитают использовать для задач САПР дешевые персональные компьютеры “желтой” сборки. Справедливости ради надо отметить, что разница в возможностях рабочих станций и самых мощных персональных компьютеров в последнее время существенно уменьшилась, хотя по-прежнему есть. Так подсистемы конструкторского проектирования сложных сборочных чертежей для авиастроения и автомобилестроения эффективно работают только на рабочих станциях.

В заключении разговора о компьютерах приведу несколько наиболее покупаемых в России модификаций рабочих станций:

- Sun SPARC Solaris, Sun SPARC SunOS;

- Alpha (Digital);

- IRIX (SGI);

- HP-UX;

- IBM AIX/600.

О лингвистическом обеспечении САПР. Основу лингвистического обеспечения САПР составляют, так называемые, проблемно-ориентированные языки, предназначенные для описания процедур автоматизированного проектирования. Собственно говоря, это и не языки вовсе, а комплексы программных средств, в качестве входных данных использующие языковые конструкции. В качестве “классического” примера можно привести язык СТЕП-Ш, разработанный преподавателем кафедры “Прикладная геометрия и автоматизация проектирования” УГТУ-УПИ Николаем Евгеньевичем Возмищевым под научным руководством проф. Р.А. Вайсбурда. Это ориентированный на конечного пользователя-непрограммиста технологический язык для описания информации о процессе и условиях проектирования в горячештамповочном производстве, а также методах решения проектных задач.

Разумеется, что в состав лингвистического обеспечения САПР входят и универсальные алгоритмические языки высокого уровня и различного типа “макроязыки”, расширяющие языковые средства больших программных систем и т.д.

Как уже отмечалось выше, стандарты по САПР выделяют еще 2 типа обеспечения САПР: методическое и организационное. Выделение это, на наш взгляд, достаточно искусственное, но “стандарт есть стандарт”. Под методическим обеспечением понимается набор документов, регламентирующих эксплуатацию САПР. Причем документы, касающиеся разработки САПР, сюда не входят. Т.е. методическое обеспечение - это, в общем смысле, просто набор инструктивных положений, касающихся эксплуатации САПР.

Организационное обеспечение также представляет собой комплекс регламентирующих документов, но уже касающихся организационной структуры подразделений, эксплуатирующих САПР, а также взаимодействия этих подразделений с САПР и между собой. В набор организационных документов входят обычно приказы, штатные расписания, квалификационные требования и т.д.

3.4. Особенности систем управления проектированием и проектными данными. Понятие об открытых системах

К проектированию АС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных автоматизированных систем.

Сущность первого направления можно охарактеризовать словами “Системная интеграция” (другое близкое понятие имеет название — консалтинг). Разработчик АС должен быть специалистом в области системотехники, хорошо знать соответствующие международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-cредствами) и быть готовым к восприятию и анализу автоматизируемых процессов в сотрудничестве с специалистами-прикладниками.

Существует ряд фирм, специализирующихся на разработке проектов АС (например, Price Waterhouse, Jet Info, Consistent Software, Interface и др.).

Второе направление в большей мере относится к области разработки математического и программного обеспечений для реализации функций АС — моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т.п. Существует ряд общеизвестных технологий (методик) проектирования ПО АС, среди которых прежде всего следует назвать компонентно-ориентированную разработку — технологию индустриальной разработки программных систем СВD.

Для каждого класса АС (САПР, АСУ, геоинформационные системы и т.д.) можно указать фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Многие из них на основе одной из базовых технологий реализуют свой подход к созданию АС и придерживаются стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.

В России действует государственный стандарт на стадии создания автоматизированных систем ГОСТ 34.601-90. Существует и международный стандарт на стадии жизненного цикла программной продукции (ISO 12207:1995). Как собственно АС, так и компоненты АС являются сложными системами и при их проектировании можно использовать один из стилей проектирования:

— нисходящее (Top-of-Design); четкая реализация нисходящего проектирования приводит к спиральной модели разработки ПО, на каждом витке спирали блоки предыдущего уровня детализируются, используются обратные связи (альтернативой является так называемая каскадная модель, относящаяся к поочередной реализации частей системы);

— восходящее (Bottom-of-Design);

— эволюционное (Middle-of-Design).

Чаще всего используется нисходящий стиль блочно-иерархического проектирования.

Рассмотрим этапы нисходящего проектирования АС.

Верхний уровень проектирования АС часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90 эти стадии называют формированием требований к АС, разработкой концепции АС и эскизным проектом).

Предпроектные исследования проводят путем анализа (обследования) деятельности предприятия (компании, учреждения, офиса), на котором создается или модернизируется АС. При этом нужно получить ответы на вопросы: что не устраивает в существующей технологии? Что можно улучшить? Кому это нужно и, следовательно, каков будет эффект? Перед обследованием формируются и в процессе его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота и т.п. Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков, имеющихся опыта и средств автоматизации. Обследование проводят системные аналитики (системные интеграторы) совместно с представителями организации-заказчика.

На основе анализа результатов обследования строят модель, отражающую деятельность предприятия на данный момент (до реорганизации). Такую модель называют “As Is”. Далее разрабатывают исходную концепцию АС. Эта концепция включает в себя предложения по изменению структуры предприятия, взаимодействию подразделений, информационным потокам, что выражается в модели “To Be” (как должно быть).

Результаты анализа конкретизируются в ТЗ на создание АС. В ТЗ указывают потоки входной информации, типы выходных документов и предоставляемых услуг, уровень защиты информации, требования к производительности (пропускной способности) и т.п. ТЗ направляют заказчику для обсуждения и окончательного согласования.

Эскизный проект (техническое предложение) представляют в виде проектной документации, описывающей архитектуру системы, структуру ее подсистем, состав модулей. Здесь же содержатся предложения по выбору базовых программно-аппаратных средств, которые должны учитывать прогноз развития предприятия.

В отношении аппаратных средств и особенно ПО такой выбор чаще всего есть выбор фирмы-поставщика необходимых средств (или, по крайней мере, базового ПО), так как правильная совместная работа программ разных фирм достигается с большим трудом. В проекте может быть предложено несколько вариантов выбора. При анализе выясняются возможности покрытия автоматизируемых функций имеющимися программными продуктами и, следовательно, объемы работ по разработке оригинального ПО. Подобный анализ необходим для предварительной оценки временных и материальных затрат на автоматизацию. Учет ресурсных ограничений позволяет уточнить достижимые масштабы автоматизации, подразделить проектирование АС на работы первой, второй и т.д. очереди.

После принятия эскизного проекта разрабатывают прототип АС, представляющий собой набор программ, эмулирующих работу готовой системы. Благодаря прототипированию можно не только разработчикам, но и будущим пользователям АС увидеть контуры и особенности системы и, следовательно, заблаговременно внести коррективы в проект.

Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций. Формализация нужна для однозначного понимания исполнителями и заказчиком требований, ограничений и принимаемых решений.

При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают моделипреобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АС модели, как правило, претерпевают существенные изменения (переход от “As Is” к “To Be”) и в окончательном виде модель “To Be” рассматривают в качестве модели проектируемой АС.

Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. информационные модели отражают структуры данных — их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий, осуществляется привязка ко времени. Структурные модели характеризуют морфологию системы (ее построение) — состав подсистем, их взаимосвязи.

Содержанием последующих этапов нисходящего проектирования (согласно ГОСТ 34.601-90 это стадии разработки технического проекта, рабочей документации, ввода в действие) является уточнение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование БД и их первоначального наполнения, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования. Эти работы составляют содержание рабочего проектирования. После этого следуют закупка и инсталляция программно-аппаратных средств, внедрение и опытная эксплуатация системы.

Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АС имеет сетевую структуру.

Если территориально АС располагается в одном здании или в нескольких близко расположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной локальной сетью типа FDDI или высокоскоростной Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т.п.

Если АС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым по причине высокой цены. Естественно, что при этом прежде всего рассматривается возможность использования услуг Internet. Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

Обеспечение открытости автоматизированных систем.Одной из главных тенденций современной индустрии информатики является создание открытых систем. Свойство открытости означает, во-первых, переносимость (мобильность) ПО на различные аппаратные платформы, во-вторых, приспособленность системы к ее модификациям (модифицируемость или собственно открытость) и комплексированию с другими системами с целью расширения ее функциональных возможностей и (или) придания системе новых качеств (интегрируемость).

Переход к открытым информационным системам позволяет существенно ускорить научно-технический прогресс в результате замены длительной и дорогостоящей разработки новых систем по полному циклу их компоновкой из ранее спроектированных подсистем или быстрой модернизацией уже существующих систем (реинжиниринг) .

Открытость подразумевает выделение в системе интерфейсной части (входов и выходов), обеспечивающей сопряжение с другими системами или подсистемами, причем для комплексирования достаточно располагать сведениями только об интерфейсных частях сопрягаемых объектов. Если же интерфейсные части выполнены в соответствии с заранее оговоренными правилами и соглашениями, которых должны придерживаться все создатели открытых систем определенного приложения, то проблема создания новых сложных систем существенно упрощается. Из этого следует, что основой создания открытых систем является стандартизация и унификация в области информационных технологий.

Значительное развитие концепция открытости получила в области построения вычислительных сетей, что нашло выражение в эталонной модели взаимосвязи открытых систем, поддерживаемой рядом международных стандартов. Идеи открытости широко используются при построении программного, информационного и лингвистического обеспечений автоматизированных систем; в результате повышается степень универсальности программ и расширяются возможности их адаптации к конкретным условиям.

Аспекты открытости выражаются в стандартизации:

— API (Application Program Interface) — интерфейсов прикладных программ с операционным окружением, в том числе системных вызовов и утилит ОС, т.е. связей с ОС;

— межпрограммного интерфейса, включая языки программирования;

— сетевого взаимодействия;

— пользовательского интерфейса, в том числе средств графического взаимодействия пользователя с ЭВМ;

— средств защиты информации.

Стандарты, обеспечивающие открытость ПО, в настоящее время разрабатываются такими организациями, как ISO (International Standard Organization), IEEE (Institute of Electrical and Electronics Engineers), EIA (Electronics Industries Association) и рядом других.

Выше уже были отмечены телекоммуникационные и сетевые стандарты семиуровневой модели взаимосвязи открытых систем (ЭМВОС).

Стандарты POSIX (Portable Operating System Interface) предназначены для API и составляют группу стандартов IEEE 1003. В этих стандартах содержатся перечень и правила вызова интерфейсных функций, определяются способы взаимодействия прикладных программ с ядром ОС на языке С (что означает преимущественную ориентацию на ОС Unix), даны расширения для взаимодействия с программами на других языках, способы тестирования интерфейсов на соответствие стандартам POSIX, правила административного управления программами и данными и т.п.