Как работает программное обеспечение сертификации продукции? От технического досье до сертификата

Что делает программное обеспечение сертификации продукции?

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

Цель не в том, чтобы быстрее выпускать PDF-файл сертификата. Главная цель — уметь показать, какой продукт по каким техническим требованиям, с какими образцами и доказательствами оценивался, на какую версию досье опирается решение и повлияло ли последующее изменение на область сертификата. Программное обеспечение упорядочивает эту цепочку доказательств; оно не подменяет компетентность органа по оценке соответствия, правила владельца программы, обязательства производителя или решение уполномоченного лица.

Что определяют ISO/IEC 17065 и ISO/IEC 17067?

ISO/IEC 17065 устанавливает требования к организациям, проводящим сертификацию продукции, процессов и услуг; ISO/IEC 17067 предоставляет базовое руководство для понимания, разработки и эксплуатации программ сертификации продукции.

По странице статуса ISO от 11 июля 2026 г. ISO/IEC 17065:2012 по-прежнему является действующей редакцией; в 2024 г. он был пересмотрен и подтверждён, и ожидается, что в ближайшие месяцы его заменит ISO/IEC FDIS 17065. ISO/IEC 17067:2013 также остаётся действующей редакцией; для второго издания ISO/IEC FDIS 17067 находится в стадии разработки. Эта переходная картина показывает, что программное обеспечение должно управлять стандартом не только по названию, а с учётом издания, версии программы и даты вступления в силу. [1] [2]

TÜRKAK рассматривает аккредитацию органов по сертификации продукции в рамках TS EN ISO/IEC 17065, применимых обязательных документов EA/IAF и руководств. В зависимости от деятельности, требуемой продуктом или программой, могут также применяться требования ISO/IEC 17025 для испытаний, ISO/IEC 17020 для инспекции и ISO/IEC 17021-1 для аудита систем менеджмента. Следовательно, программное обеспечение сертификации продукции — это не просто модуль документов, а слой оркестрации, связывающий разные источники оценки в одном досье решения. [3]

Из каких шагов состоит цифровой поток от технического досье до сертификата?

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

В заявке сначала определяется продукт или программа?

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

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

Выбор программы не должен производиться случайным образом из выпадающего списка. Следует совместно рассматривать владельца программы, нормативный документ, схему сертификации, требуемые оценочные деятельности, подход к надзору, использование знака и область полномочий организации. ISO/IEC 17067 даёт рамки для понимания и работы программ; однако сам по себе он не определяет, какое законодательство или модуль применяются к конкретному продукту. [2]

Как папка технического досье превращается в прослеживаемую модель данных?

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

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

Решение ЕС № 768/2008/EC содержит общую рамку, предусматривающую, что производитель готовит необходимую техническую документацию и выполняет или обеспечивает выполнение применимой процедуры оценки соответствия; техническая документация должна охватывать объём, позволяющий оценить соответствие продукта применимым требованиям. Элементы, такие как чертежи, описания, применённые стандарты и оценка рисков, приводятся в текстах модулей как примеры. Этот источник не говорит, что одного и того же технического досье достаточно для любого продукта; определяющими являются отраслевое законодательство и модуль. [4]

Как связываются записи об образцах, испытаниях и инспекции?

Каждый результат оценки должен привязываться к корректной идентичности продукта и образца, применённому методу, лаборатории или источнику инспекции и неизменяемой версии отчёта.

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

Если программа оценки включает аудит места производства, план, команда, площадка, процессы, доказательства и обнаружения связываются с досье продукта. Аудит системы менеджмента, испытание продукта и инспекция продукта — разные виды деятельности; программное обеспечение не должно объединять их все под названием «отчёт об аудите», теряя различие методов и компетентности. Разъяснение TÜRKAK по сертификации продукции в этом отношении наглядно показывает, что в зависимости от программы могут применяться требования ISO/IEC 17025, ISO/IEC 17020 или ISO/IEC 17021-1. [3]

Может ли сертификат публиковаться автоматически после закрытия несоответствия?

Нет. Устранение несоответствия, завершение оценочного досье и шаг уполномоченного анализа/решения должны быть разделены; программное обеспечение должно лишь поддерживать контроль и поток доказательств.

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

Экран решения может суммировать результаты, показывать противоречия и блокировать незаполненные обязательные поля. Однако решения — выдача сертификата, сужение области, требование дополнительной оценки, приостановка или отзыв — должны приниматься уполномоченными лицами с обоснованием согласно программе и процедуре организации. Если позже изменится отчёт об испытании, старое решение не должно молча привязываться к новому отчёту; следует открыть анализ влияния.

Как контролируются область сертификата и использование знака?

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

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

Программное обеспечение не должно превращать библиотеку логотипов или знаков соответствия в свободную область дизайна. Знак CE, знак аккредитации, знак программы и логотип органа по сертификации подчиняются разным правовым и договорным правилам. Без верификации полномочий, области, графических правил и согласования использования знак не должен добавляться в документ. Фраза «система выпустила сертификат» сама по себе не доказывает соответствие продукта законодательству или аккредитованные полномочия организации.

Сертификация продукции и CE с техническим регулированием — один и тот же процесс?

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

Синее руководство Европейской комиссии 2022 года — исчерпывающее руководство, разъясняющее применение правил ЕС о продукции; само руководство не является обязательным законодательным текстом, юридическая сила заключена в соответствующем законодательстве Союза о гармонизации. Оно совместно рассматривает роли экономических операторов, техническую документацию, органы по оценке соответствия, аккредитацию, рыночный надзор и границы, относящиеся к знаку CE. Поэтому в программном обеспечении запись целевого рынка продукта и применимого законодательства является более корректной отправной точкой, чем общая «сертификация CE». [5]

В Турции в рамках Закона № 7223 о безопасности продукции и технических регулированиях продукты должны соответствовать применимому техническому регулированию; официальная страница FAQ Министерства торговли указывает, что без устранения несоответствия продукт не может быть выпущен на рынок, находиться на рынке или вводиться в эксплуатацию. Постановление о методах оценки соответствия разъясняет, что модуль или модули, применяемые для продукта, указываются в соответствующем техническом регулировании. Программное обеспечение может предложить библиотеку правил, помогающую выбрать законодательство; окончательный выбор должны определять актуальный официальный текст и уполномоченная оценка. [6] [7]

Почему изменения продукта и надзор отслеживаются в одном досье?

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

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

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

Какие записи разделяет надёжная модель данных сертификации продукции?

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

• Семейство продуктов: Связь базовой модели, варианта и критического компонента.
• Матрица требований: Техническое регулирование, пункт стандарта/программы и статус доказательства.
• Версия документа: Издатель файла, дата, область продукта и связь с предыдущей версией.
• Цепочка образцов: Приёмка, идентичность, хранение, отправка, испытание/инспекция и запись о возврате/уничтожении.
• Внешняя оценка: Порученная организация, область, отчёт и результат технической проверки.
• Связь решения: Оценки и версии досье, использованные решением.
• Цикл сертификата: Публикация, ревизия, приостановка, отзыв, срок действия и статус верификации.
• Влияние изменения: Изменённый элемент, затронутое доказательство, требуемая деятельность и решение.

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

Как планировать переход на программное обеспечение сертификации продукции?

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

1. Составьте перечень программы и документов

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

2. Постройте дерево доказательств на одном семействе продуктов

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

3. Протестируйте поток внешней лаборатории/инспекции

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

4. Проверьте решение и ревизию сертификата

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

Каковы самые частые ошибки в программном обеспечении сертификации продукции?

Крупнейшие ошибки: считать CE и сертификат синонимами, растворять варианты под одним продуктом и автоматически принимать доказательство при загрузке файла.

• Фиксировать программу: Использовать один и тот же перечень требований для каждого продукта и рынка.
• Доверяться имени файла: Оставлять связь продукта, версии и требования только на имени файла.
• Терять след образца: Не связывать результат испытания с корректной серией/партией и вариантом.
• Автоматически утверждать внешний отчёт: Не пропускать соответствие области, метода и продукта через техническую проверку.
• Привязывать решение к выпуску PDF: Использовать формирование документа вместо уполномоченного решения.
• Свободно использовать знаки: Добавлять знак CE или знак аккредитации/программы без проверки полномочий и графических правил.
• Хранить изменение как заметку: Не оценивать влияние ревизии продукта на доказательства и сертификат.

Как Vizyon Cert поддерживает процесс сертификации продукции?

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

На странице решения Vizyon Cert вы можете изучить модульную структуру сертификационной операции. В рамках услуги по программному обеспечению сертификации анализируются действующие программы, формы, решения и интеграции, и проектируется подходящая модель данных. Установка программного обеспечения не означает, что организация автоматически соответствует ISO/IEC 17065 или аккредитована; процессы и применение должны подтверждаться уполномоченными оценками.

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

Часто задаваемые вопросы