Hls структура

In earlier days playing videos through online was tremendously challenging. If a video has to be played in different screen sizes with different internet speed, it was not an easy task as the internet speed would be entirely different in both rural and urban areas. Earlier if the video source is HD, the same video will be played as the output. And because of the source file size, the video was not possible to be played on low bandwidth i.e 2G network.

In 2009, Apple came up with a solution called HTTP Live Streaming or HLS protocol.

Role of HLS protocol

In order to optimize the media source, this protocol encodes as segments (.ts) of media files from servers to devices by rendering the content in different bitrate versions and splits into multiple chunks.

HLS Architecture

HLs uses a standard web server for distributing audio and video content. And It requires a specific software (FFmpeg, avconv etc) to fit into the proper format transmission in real time.

The server component encapsulates the input video flow in a proper format for the delivery. The video is then segmented it into different files for distribution. During the process of intake, the video is encoded and segmented in order to generate video fragments and index file.

• Encoder: Organizes the video files in H.264 format and audio in AAC, MP3, AC-3 or EC-3. Then outputs it in an MPEG-2 transport stream.
• Segmenter: The stream segmenter divides the MPEG-2 TS file into a series of short media files of equal length saved as .ts files. It also creates and maintains an index file which contains references of the fragmented files, saved as .m3u8. HLS recommended segment .ts size is 10 seconds. To have better encoding efficiency and flexibility for stream adaption to bandwidth changes, HLS chunk sizes can be customized around 2 to 4 seconds.

The distributor component consists of standard web server. It accepts client requests and delivers all the resources (.m3u8 playlist file and .ts segment files) required for streaming.

Advantages of HLS streaming

Below I’ve mentioned some of the major advantages in terms of video streaming quality:

• The broadcasters can easily deliver audio or video streams using the adaptive bitrate process supported by HLS. As a result of this, every viewer can experience the best quality stream based on the internet connection.
• The viewers can switch to any bitrate version at any time.
• The HLS streaming protocol is widely supported by all client software like iPhones, iPads, and the iPod Touch, Google Chrome, Safari, Microsoft Edge, iOS, Android, Linux, Microsoft, and MacOS platforms.
• As most of the clients supports MPEG DASH, but clients like Apple Safari and iOS devices does not support it. In that way, HLS would always be a better choice.

Disadvantages of HLS streaming

Even though we have so many advantages, here are a few cons why one would not use HLS streaming:

• HLS can be overpowered in terms of quality. But when it comes to latency, it is not built for delivering video quickly. In real-time HLS results in minimum of 20 seconds of latency.
• The HTTP live streaming requires at least 3 segments to remain in queue before it allows the video playback.
• HTTP live streaming is limited by its key frame interval, buffer requirements and packet size, pushing your stream back a delay between 20 to 60 seconds. Therefore, such scenario results as a major drawback in live streaming events.
• HLS only supports playing streams. Unlike WebRTC that has a spec for publishing from a browser, HLS is a subscriber-only protocol.

Conclusion

As there are various advantages for choosing HLS streaming, there are quite a few cons where one has to give it a thought especially when going for live streaming. So choosing HLS protocol mainly depends upon your purpose of video content that you are going to stream. If you consider only the video quality then going for HLS streaming is a great choice. But when you go for interaction based live streaming purpose without latency issue, then just have to go for some other protocol.

Обзор HLS

Полное название HLS – HTTP Live Streaming – протокол потоковой передачи мультимедиа на основе HTTP, реализованный Apple. Он очень похож на принцип протокола DASH. Разрезая весь поток в небольшой медиафайл, который можно загрузить через HTTP, затем Предоставьте клиенту файл вспомогательного списка мультимедиа и позвольте клиенту извлекать эти мультимедийные файлы для воспроизведения, чтобы добиться эффекта воспроизведения потока.

Поскольку протокол транспортного уровня требует только стандартного протокола HTTP, HLS может легко проходить через брандмауэр или прокси-сервер и легко использовать CDN для ускорения распространения, а клиент также очень удобен для реализации.

HLS в настоящее время широко используется в области трансляции по запросу и прямой трансляции.

Использование HLS на страницах HTML5 очень просто:

1. <video src="example.m3u8" controls></video>

Далее я представлю все аспекты протокола HLS (и включу содержимое части шифрования AES) в целом, и лучше работать с RFC HLS.

Подробный протокол HLS

Приведенный выше hls_arch представляет собой общую диаграмму архитектуры HLS. Можно видеть, что есть три части: сервер, CDN, клиент.

На самом деле основное содержание протокола HLS касается текстового протокола M3U8. На самом деле генерация и синтаксический анализ очень просты. Чтобы проиллюстрировать это более непосредственно, я приведу два простых примера:

Главный плейлист с несколькими битрейтами:

• HLS представляет поток мультимедиа через список воспроизведения, на который указывает URI (RFC3986).

• Список воспроизведения может быть списком воспроизведения мультимедиа или основным списком воспроизведения, текстовым файлом в кодировке UTF-8, содержащим некоторые идентификаторы URI и описательные теги.

• Список воспроизведения мультимедиа содержит список сегментов мультимедиа, который при последовательном воспроизведении может воспроизводить весь полный поток.

• Чтобы воспроизвести этот список воспроизведения, клиент должен сначала загрузить его, а затем воспроизвести каждый сегмент мультимедиа в нем.

• Более сложный случай состоит в том, что Playlist является Master Playlist, который содержит коллекцию Variant Stream, обычно каждый

• Variant Stream содержит несколько разных версий одного и того же потока (например, разные разрешения и разные битрейты).

HLS Media Segments

• Каждый сегмент мультимедиа определяется URI и может содержать диапазон байтов.

• Продолжительность каждого сегмента мультимедиа определяется тегом EXTINF.

• Каждый медиа-сегмент имеет уникальный целочисленный номер медиа-сегмента.

• Для некоторых форматов мультимедиа требуется последовательность, специфичная для формата, для инициализации синтаксического анализатора до синтаксического анализа сегмента мультимедиа. Это поле называется разделом инициализации мультимедиа и определяется тегом EXT-X-MAP. Поддерживаемые форматы сегмента мультимедиа

MPEG-2 Transport Streams

Это самый распространенный файл TS.

• Раздел инициализации носителя: PAT (Таблица ассоциации программ) и PMT (Таблица карт программ).

• Каждый сегмент TS должен содержать программу MPEG-2.

• Каждый сегмент TS содержит PAT и PMT, предпочтительно в начале сегмента или указанный тегом EXT-X-MAP.

Fragmented MPEG-4

Это часто называют fMP4.

• Раздел инициализации мультимедиа: поле ftyp (включая марку выше ios6), поле ftypbox должно следовать непосредственно за блоком moov. Блок moov должен содержать поле trak (для каждого блока traf в сегменте fMP4 он содержит соответствующий track_ID). В trakbox должна быть таблица с примерами, но количество отсчетов должно быть равно 0. Продолжительность полей mvhd и tkhd должна быть 0. Поле mvex должно следовать за предыдущим блоком trak.

• В отличие от обычных файлов MP4, которые содержат блок moov (содержащий примеры таблиц) и mdatbox (содержащий соответствующие образцы), fMP4 содержит блок moof (содержащий подмножество таблиц образцов) и блок mdat (содержащий соответствующие образцы) ,

• В каждом сегменте fMP4 каждый блок трафика должен содержать поле tfdt, а сегмент fMP4 должен использовать относительную адресацию фрагмента фильма.Сегменты FMP4 не должны использовать ссылки на внешние данные.

• Каждый сегмент fMP4 должен иметь тег EXT-X-MAP.

Packed Audio

• Сегментированный аудиосегмент содержит кодированные аудиосэмплы и теги ID3, он просто упакован вместе, содержит минимальное кадрирование и не имеет отметки времени для сэмпла.

• Сегмент упакованного аудио не имеет секции инициализации мультимедиа.

• Каждый упакованный аудиосегмент должен передавать тег ID3 PRIV на отметке времени, указанной в его первом примере.

• Идентификатор владельца ID3 PRIV должен быть com.apple.streaming.transportStreamTimestamp.

• Полезная нагрузка ID3 должна представлять собой восьмеричное число с прямым порядком байтов 33-битной временной метки элементарного потока программы MPEG-2, где для высокого значения 31 установлено значение 0.

WebVTT

• Сегмент WebVTT – это раздел файла WebVTT. Сегмент WebVTT содержит субтитры. Раздел инициализации мультимедиа: заголовок WebVTT.

• Каждый сегмент WebVTT должен начинаться с заголовка WebVTT или иметь тег EXT-X-MAP для его указания.

• Каждый заголовок WebVTT должен иметь X-TIMESTAMP-MAP для обеспечения синхронизации аудио и видео.

HLS Playlists

Формат файла списка воспроизведения получен из M3U и наследует два тега: EXTM3U и EXTINF. Приведенные ниже теги определяются синтаксисом в стиле BNF.

• Файл списка воспроизведения должен быть идентифицирован URI (.m3u8 или m3u) или HTTP-типом контента (application / vnd.apple.mpegurl или audio / mpegurl).

• Символы новой строки могут быть \ n или \ r \ n.

• Теги, начинающиеся с #, являются тегами или комментариями, теги, начинающиеся с #EXT, являются тегами, а остальные являются комментариями, и их следует игнорировать при синтаксическом анализе.

• URI в списке воспроизведения может использовать абсолютный адрес или относительный адрес. Если используется относительный адрес, он относится к адресу файла списка воспроизведения.

Attribute Lists

• Значением некоторых тегов являются списки атрибутов.

• Список атрибутов – это разделенный запятыми список пар атрибут / значение.

• Формат: AttributeName = AttributeValue.

Basic Tags

Основные теги могут быть использованы в медиа-плейлистах и ​​мастер-плейлистах.

• EXTM3U: Должен быть в первой строке файла, логотип является файлом расширенного списка воспроизведения M3U.

• EXT-X-VERSION: указывает версию, совместимую с плейлистом.

Media Segment Tags

Каждый сегмент мультимедиа определяется серией тегов сегмента мультимедиа и URI. Некоторые теги сегмента мультимедиа применяются только к следующему сегменту, в то время как другие применяют все следующие сегменты. Тег сегмента мультимедиа может появляться только в списке воспроизведения мультимедиа. ,

• EXTINF: используется для указания продолжительности медиа сегмента

• EXT-X-BYTERANGE: поддиапазон для указания URI

• EXT-X-DISCONTINUITY: указывает на разрыв.

• EXT-X-KEY: указывает, что мультимедийный сегмент зашифрован. Это значение используется для расшифровки.

• EXT-X-MAP: используется для указания раздела инициализации носителя.

• EXT-X-PROGRAM-DATE-TIME: определите отметку времени с помощью первого образца сегмента мультимедиа.

• EXT-X-DATERANGE: объединяет временной диапазон с набором пар ключ-значение атрибута.

Media Playlist Tags

Теги Media Playlist описывают глобальные параметры Media Playlist Аналогичным образом, теги Media Playlist могут появляться только в Media Playlist.

• EXT-X-TARGETDURATION: используется для указания максимальной продолжительности медиа сегмента.

• EXT-X-MEDIA-SEQUENCE: Используется для указания номера последовательности мультимедиа первого сегмента мультимедиа.

• EXT-X-DISCONTINUITY-SEQUENCE: Используется для синхронизации между различными потоками вариантов.

• EXT-X-PLAYLIST-TYPE: Необязательно, указывает тип всего списка воспроизведения.

• EXT-X-I-FRAMES-ONLY: указывает, что каждый мультимедийный сегмент описывает один I-кадр.

Master Playlist Tags

Теги мастер-плейлиста определяют Variant Streams, Renditions и другие отображаемые глобальные параметры. Теги мастер-плейлиста могут появляться только в мастер-плейлисте.

• EXT-X-MEDIA: несколько воспроизведений для связывания нескольких списков воспроизведения мультимедиа для одного и того же контента.

• EXT-X-STREAM-INF: Используется для указания потока вариантов.

• EXT-X-I-FRAME-STREAM-INF: I-кадры, используемые для указания того, что список воспроизведения мультимедиа содержит медиа.

• EXT-X-SESSION-DATA: сохранить некоторые данные сеанса.

• КЛАВИША EXT-X-SESSION: Используется для расшифровки.

Media or Master Playlist Tags

Приведенные здесь теги могут появляться в Media Playlist или Master Playlist, но если они появляются в одном и том же Master Playlist и Media Playlist одновременно, они должны иметь одинаковое значение.

• EXT-X-INDEPENDENT-SEGMENTS: указывает, что каждый медиа сегмент может быть декодирован независимо.

• EXT-X-START: указывает предпочитаемую точку для воспроизведения этого плейлиста.

Серверная и клиентская логика

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

Серверная логика

• 1. При разделении источника мультимедиа на сегмент мультимедиа его следует преимущественно разрезать с момента времени, который может быть эффективно декодирован (например, I-кадр).

• 2.Создайте URI для каждого медиа-сегмента.

• 3. Сервер должен поддерживать «gzip» для сжатия текстового содержимого.

• 4. Создайте индексный файл списка воспроизведения мультимедиа, EXT-X-VERSION не должен быть выше, чем версия, которая ему необходима для обеспечения лучшей совместимости.

• 5. Сервер не может изменять Media Playlist по своему усмотрению, за исключением добавления текста в конец файла, удаления URI Media Segment по порядку, увеличения EXT-X-MEDIA-SEQUENCE и EXT-X-DISCONTINUITY-SEQUENCE, добавления EXT-X-ENDLIST в конец ,

• 6. Добавьте в конце тег EXT-X-ENDLIST, чтобы уменьшить количество клиентских перезагрузок списков воспроизведения.

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

Клиентская логика

• 1. Клиент получает список воспроизведения через URI. Если это основной список воспроизведения, клиент может выбрать вариант воспроизведения потока.

• 2. Клиент проверяет, соответствует ли версия EXT-X-VERSION.

• 3. Клиент должен игнорировать нераспознанные теги и игнорировать пары ключ-значение нераспознанного атрибута.

• 4. Загрузите файл списка воспроизведения мультимедиа.

• 5. Воспроизведите файл списка воспроизведения мультимедиа.

• 6. Перезагрузите файл списка воспроизведения мультимедиа.

• 7. Определите, какой медиа сегмент будет загружен следующим.

Преимущества HLS

• Поддержка клиента проста, поскольку он поддерживает запросы HTTP, протокол HTTP не имеет состояния и вам нужно только загружать медиаклипы по порядку.

• Использование протокола HTTP обеспечивает хорошую совместимость с сетью, пакеты HTTP также могут легко проходить через брандмауэр или прокси-сервер, а поддержка CDN хорошая.

• Полный спектр поддержки Apple. Поскольку HLS был предложен Apple, весь спектр продуктов Apple, включая iphone, ipad и safari, может поддерживать воспроизведение HLS без установки каких-либо плагинов. Теперь в Android также добавлена ​​поддержка HLS. ,

• Имея собственную многоскоростную адаптацию, Apple уже рассмотрела проблему потоковой адаптации, когда предложила HLS.

Недостатки HLS

• По сравнению с протоколами с длинными соединениями, такими как RTMP, задержка выше, и трудно использовать интерактивные сценарии прямой трансляции.

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

Улучшенная технология HLS

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

Здесь в основном представлены варианты HLS сетевого приемника и HLS + облака.

Вариант ЗОЖ на Нетстай

Сначала мы можем загрузить файл M3U8 для сетевого приемника:

Затем откройте загруженный файл списка воспроизведения:

Можно видеть, что это главный список воспроизведения с вложенным в него слоем M3U8, и можно видеть, что сетевой приемник использует wsSession для идентификации соединения воспроизведения.

HLS + другого облака

Затем откройте загруженный файл списка воспроизведения:

6. #EXTINF:0.998, no desc

Можно видеть, что HLS +, который также снимает облако, также поддерживает этот вариантный метод HLS для идентификации соединения HLS. Можно видеть, что Uiyun использует uuid для представления соединения HLS.

HTTP 302

Сначала адрес воспроизведения запрашивается в HTTP 302.

Открыть список воспроизведения контента:

1. Redirect to http://183.158.35.19:8080/uplive.b0.upaiyun.com/live/loading.m3u8?

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

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

Анализ задержки HLS

Теоретическая задержка HLS = 1 длительность среза + 0-1 td (td – EXT-X-TARGETDURATION, просто понимается как интервал между выборками игроков) + 0-n стартовых срезов (официальное предложение Apple по запросу (Воспроизведение не начнется до тех пор, пока 3 среза) + Сетевая задержка среза, запрошенного игроком в начале (это требует много времени для сетевого подключения) Чтобы добиться эффекта низкой задержки, срез может быть обрезан меньше, а интервал между выборками может быть уменьшен. Проигрыватель начинает воспроизведение перед загрузкой 3 фильмов, однако эти методы оптимизации увеличат риск нестабильности HLS и ошибок.

Играть в незашифрованном HLS

1. Мы знаем, что видео формата HLS поддерживается только в Android 4.0 и выше. В настоящее время базовая версия 4.0 может рассматриваться и не совместима. Поэтому, чтобы уменьшить рабочую нагрузку, не планируется использовать сторонний проигрыватель и продолжать использовать MediaPlayer. игра

2. В видео формата HLS он передает файл m3u8, который затем содержит несколько фрагментов файла TS. Вот официальный пример от Apple:

В конце концов, это разработано Apple, поэтому, безусловно, правильно смотреть на официальный формат.

Мы видим, что у него есть еще один видеоклип, один за другим – это то, что нам нужно воспроизвести, так как он распознается и воспроизводится проигрывателем.

4. Фактически, все вышеперечисленные ключевые поля согласованы, поэтому в собственном слое класса MediaPlayer файл m3u8 будет проанализирован в соответствии с указанными полями, так какой конечный адрес он воспроизводил в проигрывателе? Это так

Сгруппированные вместе, вы можете играть непосредственно с этим адресом, чтобы увидеть.

5. Лучше реализовать этот незашифрованный кеш, который можно разделить на эти шаги.

• А. Сначала мы анализируем этот файл m3u8 в соответствии с определенным форматом.

• б. В соответствии с проанализированными файлами TS они собираются в соответствии с известными нам правилами, загружают эти файлы TS и сохраняют их на SD-карте мобильного телефона.

• В. Нам нужно настроить локальный http-сервер локально. Мы планировали построить https раньше, но поскольку сгенерированный сертификат был сгенерирован нами, проигрыватель не получил доступ к локальному серверу.

• г. На локальном сервере мы фильтруем определенные имена интерфейсов, чтобы получить разные видеофайлы на основе разных имен ts (лучше всего генерировать то же имя, что и исходный файл ts)

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

Воспроизвести зашифрованный HLS

Посмотрите на формат зашифрованного файла m3u8

Мы видим дополнительное поле EXT-X-KEY. Это также зашифрованное поле, предоставляемое m3u8. Если поле включено, проигрыватель сначала запросит этот ключ, а затем использует этот ключ для доступа к зашифрованному видео TS. играл. Фактически, когда мы видим это, мы должны думать о том, как это сделать, и зашифрованный кеш воспроизводится.

Реализация идеи воспроизведения зашифрованного кэша

• а, мы сначала анализируем этот файл m3u8 в соответствии с определенным форматом.

• б. В соответствии с проанализированными TS-файлами, они собираются в соответствии с известными нам правилами. Они загружают эти TS-файлы и сохраняют их на SD-карту мобильного телефона. Эти загруженные TS-видеофайлы не могут быть воспроизведены, а затем загружается правильный ключ.

• В. Нам нужно настроить локальный http-сервер локально. Изначально мы планировали создать https, но поскольку сгенерированный сертификат сгенерирован нами, проигрыватель не имеет доступа к локальному серверу.

• г. Локальный сервер Мы фильтруем определенные имена интерфейсов, чтобы получить разные видеофайлы на основе разных имен ts (здесь лучше создать то же имя, что и исходный файл ts).

• д. Откуда мы знаем, что проигрыватель закончил воспроизведение видео, потому что оно воспроизводится по одному, поэтому здесь нам нужно сгенерировать локальную копию локального указателя на нас

Источник: автором статьи является Дуг Милн (Doug Milne, – ред.), она впервые опубликована на английском языке, на сайте одного из крупнейших в мире органов по сертификации «DNV GL». Штаб-квартира организации находится в Милане, Италия.

В моем первом блоге, я сделал обзор причин, по которым ISO 9001:2015 и ISO 14001:2015 обновляются, обозначил некоторые ключевые изменения в обновлениях, а также основные моменты и даты. Этот второй блог из серии сосредоточен на High Level Structure (HLS, – ред.), которая сейчас используется во всех новых и обновленных стандартах на системы менеджмента. Принцип HLS является логичной и разумной идеей для приведения в соответствие базовой структуры и содержимого всех стандартов системы менеджмента, определяется Директивами ISO (Международная организация по стандартизации – International Organization for Standardization, – ред.) в Приложении SL (На тот случай если ссылка появится в других блогах и документации).

ШАГ 2: СТРУКТУРА ВЕРХНЕГО УРОВНЯ (HLS)

Структура Высокого Уровня имеет несколько основных особенностей:

1) Включает 10 главных разделов, которые должен содержать любой стандарт системы менеджмента ISO.

2) Включает определенное количество обязательных подпунктов к 10 главным обязательным разделам.

3) К каждому обязательному разделу дано описание информации, которую он должен содержать – не только название параграфа.

Чтобы не быть голословными…

Обязательные пункты HLS следующие:

1. Область применения.
2. Нормативные ссылки.
3. Термины и определения.
4. Среда организации.
5. Лидерство.
6. Планирование.
7. Поддержка.
8. Функционирование.
9. Оценивание результатов функционирования.
10. Улучшение.

Еще раз подчеркнем, эти основные параграфы будут неизменны от стандарта к стандарту – они были согласованы в ISO в качестве структуры верхнего уровня для всех стандартов менеджмента – они уже используются в самых последних стандартах таких, как ISO 55001:2014 «Менеджмент активов. Системы менеджмента. Требования» и ISO 27001:2013 «Информационная технология. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования». В качестве примера давайте рассмотрим Пункт 4 «Среда организации». Текущие проекты ISO 9001 и ISO 14001 оба содержат обязательные подпункты разделов:

4.1 Понятие организации и ее окружения.

4.2 Понятие потребностей и ожиданий заинтересованных сторон.

4.3 Определение области применения системы менеджмента.

4.4 Система менеджмента.

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

В пункте 8 «Функционирование», единственный обязательный подпункт следующий:

8.1 Планирование функционирования и контроль.

Но здесь мы видим некоторые значительные расхождения между комитетом, занимающимся ISO 9001 и комитетом, отвечающим за ISO 14001 в дополнительных подпунктах, а именно:

Для ISO 9001:

8.2 Определение требований рынка и взаимоотношений с клиентами.

8.3 Процесс планирования операций.

8.4 Контроль за внешним предоставлением товаров и услуг.

8.5 Разработка продукции и услуг.

8.6 Производство продукции и услуг.

8.7 Продажа товаров и услуг.

8.8 Несоответствующие товары и услуги.

Для ISO 14001:

8.2 Контроль цепи издержек.

8.3 Аварийная готовность и реагирование.

Довольно много различий если все еще удерживаться в рамках концепции дополнительного содержимого! Но, с другой стороны, вовсе не так много по сравнению с Параграфом №7 в ISO 9001:2008 и пунктами 4.4.6 и 4.4.7 в ISO 14001:2004.

Итак, надеюсь вы увидели, как ISO подходит к идее имплементации единого подхода к общей структуре и большей части содержимого стандартов систем менеджмента. Причем, это нисколько не мешает отдельному стандарту на системы менеджмента полностью учитывать и раскрывать свою предметную область.

Это рассказ об аспектах, связанных с HLS. В следующем блоге я расскажу о самих изменениях, сделанных в стандартах и их структуре. Что еще более интересно и логично, так это то, что самые важные изменения являются ОДИНАКОВЫМИ для ISO 9001 и ISO 14001 – или любой системы менеджмента. Почему это логично? Потому что фундаментальные принципы любой системы менеджмента базируются на совокупности единых основных принципов.

Перевод: внештатный сотрудник «Единый Стандарт» Богдан Калошин.

Читать на сайте 1CERT.RU