Перейти к публикации

Рекомендованные сообщения

Так куда все-таки в спецификации записывать программне обеспечение? Покупное ПО (windows), поставляемое вместе с изделием и устанавливаемое у производителя в раздел Комплекты? А ПО разрабатываемое непосредственно для данного изделия и устанавливаемое на производстве куда записывается? НА ПО спецификацию выпускают по ГОСТ 19. Получается в раздел Документация тогда.

Ссылка на сообщение
Поделиться на других сайтах


А ПО разрабатываемое непосредственно для данного изделия и устанавливаемое на производстве куда записывается? НА ПО спецификацию выпускают по ГОСТ 19.

ПО оформленное по ГОСТ 19. записывают в раздел "Комплекты". В раздел "Документация" записывают "Данные программирования", в спецификацию устройства которое проходит  настройку и программирование (ПЛИС) в процессе изготовления.

Ссылка на сообщение
Поделиться на других сайтах
  • 1 месяц спустя...

ПО, разрабатываемое непосредственно для изделия в которое оно входит, включают в раздел "Комплекты" (как Прочие комплекты) - см. ГОСТ 2.106, п. 3.9 (с изменением)  - "В прочих комплектах указывают программную продукцию (программное обеспечение), поставляемое вместе с изделием. Программная продукция (документы) могут быть объединены спецификацией по ГОСТ 19.202".

И выпускают на это ПО документацию согласно ЕСПД. 

В раздел "Документация" спецификации изделия - ПО не вносится!!  В раздел "Документация" вносятся документы на Специфицируемое изделие, например АБВГ.ХХХХХХ.ХХХ, а также документы на составные части неспецифицируемые (см. ГОСТ 2.106 п. 3.4.) 

(Документ "Данные программирования", как писали выше - не верно записан, видимо имелся в виду документ "Данные проектирования", кот. представляет из себя документ в электронной форме с данными проектирования по печатным платам и имеет код Д33, согласно РД 107.460640.020. Так что это к ПО никак не относится.)

Ссылка на сообщение
Поделиться на других сайтах
Документ "Данные программирования", как писали выше - не верно записан, видимо имелся в виду документ

Смотрите РД 107.2.1002 на коды прочих документов. 

Ссылка на сообщение
Поделиться на других сайтах
  • 2 месяца спустя...

Интересует этот же вопрос.

Есть "железяка", пусть будет компьютер, для него есть общесистемный софт - например, операционная система Линукс, а также есть прикладной софт - программа верхнего уровня (не уверена в корректности термина), которая решает какие то внешние задачи, к примеру калькулятор. На оба эти софта по ЕСПД создается документация и присваивается децимальный номер. При этом компьютер должен отгружаться пользователю с предустановленным софтом.  В какие разделы должны быть включены децимальные номера софта?

Интуитивно склоняюсь к разделу "комплексы", но не могу найти подтверждения в ГОСТах (на мой взгляд вполне разумно - получаем своего рода аппаратно-программный комплекс). Согласно п. 3.9 ГОСТ 2.106, приведенному ранее, определяю для себя, что в раздел "комплекты" необходимо записывать поставляемое (отдельно, т.е. не установленное на него) ПО.

Ссылка на сообщение
Поделиться на других сайтах
что в раздел "комплекты" необходимо записывать поставляемое (отдельно, т.е. не установленное на него) ПО.

Поставляемое это значит передаете ПО потребителю на диске, предустановленным или он сам скачает с вашего сайта и тд.

В графе "Примечание" можете указать все варианты.

Ссылка на сообщение
Поделиться на других сайтах
  • 5 месяцев спустя...

Прошу поделиться опытом.

Разработали оборудование в которое входят несколько видов плат. На данный момент в работу включились программисты. Как правильно организовать совместную работу конструктор-программист, чтобы понимать друг друга однозначно? Грубо говоря, какой бумажный документ по работе оборудования нужно согласовать между нами, чтобы оборудование по написанной программе выполняло необходимые функции в требуемой последовательности? Как мне представляется, это должна быть графически оформленные блок-схема или  алгоритм работы оборудования, одинаково понятные и конструктору и программисту. Как кто делает? И кто должен делать такие документы?

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

Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Bully
Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
программисты без контроля и четкого алгоритма
простите, а в чем будет четкий алгоритм, если конструкции ещё нет? IMHO, тут однозначно идет сначала работа по созданию электроники, управляющей чем положено (а вот "чем положено" определяется в ТЗ), и уже конструктору выдается расположение контактов, по которому он выполняет конструкцию корпуса с клавишами/переключателями.
Ссылка на сообщение
Поделиться на других сайтах

простите, а в чем будет четкий алгоритм, если конструкции ещё нет? IMHO, тут однозначно идет сначала работа по созданию электроники, управляющей чем положено (а вот "чем положено" определяется в ТЗ), и уже конструктору выдается расположение контактов, по которому он выполняет конструкцию корпуса с клавишами/переключателями.

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

Ссылка на сообщение
Поделиться на других сайтах

@@alek77, это я свое видение просто описал. Чисто по логике. Я с электроникой не работал. В идеале, думается, вообще вся работа по созданию таких устройств должна происходить параллельно. Сидят в одном кабинете Вася с Петей и по мере процесса созидания у того и другого происходит корректировка.

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

Этот документ называется Техническое задание. Вам, видимо, подойдет ГОСТ 34.602.
Ссылка на сообщение
Поделиться на других сайтах
Разработали оборудование в которое входят несколько видов плат. На данный момент в работу включились программисты. Как правильно организовать совместную работу конструктор-программист, чтобы понимать друг друга однозначно? Грубо говоря, какой бумажный документ по работе оборудования нужно согласовать между нами, чтобы оборудование по написанной программе выполняло необходимые функции в требуемой последовательности?

Должна быть разработана схема электрическая принципиальная на изделие(Э3). Программисты должны руководствоваться техническим заданием на изделие в котором заданны все выполняемые функции и последовательность их выполнения.

Ссылка на сообщение
Поделиться на других сайтах
  • 4 месяца спустя...

Я так до конца и понял куда записывать прошивку для устройства, в раздел Документация? А обозначение = обозначение + Д?

А наименование Прошивка, ПО или как лучше это назвать?

Ссылка на сообщение
Поделиться на других сайтах
В 24.03.2017 в 15:44, Timi сказал:

Я так до конца и понял куда записывать прошивку для устройства, в раздел Документация? А обозначение = обозначение + Д?

А наименование Прошивка, ПО или как лучше это назвать?

Разрабатывается документ "Инструкция по программированию микросхем" И33 в которой есть ссылка на носитель с прошивкой, с наименованием "Данные программирования" Д42. Эти документы записывают в раздел "Документация" спецификации.

Ссылка на сообщение
Поделиться на других сайтах
  • 1 год спустя...

Поддерживаю предыдущего оратора. Расписано красиво и логично. ГОСТ в студию, чтоб нормоконтроль в него носом ткнуть. А то мне нормоконтроль говорит, получи-ка хлопец на ПО свой номер, да чтоб он по ЕСПД был, да засунь его в комплекты. Я им - дык какой-же это комплект, ежели он внутри, да пощупать его нельзя, ПО неотъемлемая часть ТОЛЬКО для этого изделия, зачем ему другой дец. номер и вообще конечный пользователь про него даже не догадывается. А они мне - а нам пофигу и ГОСТ 2.106-96 п.3.9 мне в рожу тычуть.... А так хочется, чтоб логично и просто...

 

Зы. Еще просьба ко всем, ежели Вы чего вкусного пишите, ссылку на ГОСТ добавляйте плиз. А то все красиво написано И Я ТАК ХОЧУ!!!! Но ГОСТа на это не найти.... (И есть-ли он вообще...)

Изменено пользователем USSR_Nic
Ссылка на сообщение
Поделиться на других сайтах
  • 3 месяца спустя...
В 20.06.2018 в 19:13, USSR_Nic сказал:

Поддерживаю предыдущего оратора. Расписано красиво и логично. ГОСТ в студию, чтоб нормоконтроль в него носом ткнуть. А то мне нормоконтроль говорит, получи-ка хлопец на ПО свой номер, да чтоб он по ЕСПД был, да засунь его в комплекты. Я им - дык какой-же это комплект, ежели он внутри, да пощупать его нельзя, ПО неотъемлемая часть ТОЛЬКО для этого изделия, зачем ему другой дец. номер и вообще конечный пользователь про него даже не догадывается. А они мне - а нам пофигу и ГОСТ 2.106-96 п.3.9 мне в рожу тычуть.... А так хочется, чтоб логично и просто...

 

Зы. Еще просьба ко всем, ежели Вы чего вкусного пишите, ссылку на ГОСТ добавляйте плиз. А то все красиво написано И Я ТАК ХОЧУ!!!! Но ГОСТа на это не найти.... (И есть-ли он вообще...)

такаж проблема, нашли что-нибудь?

Ссылка на сообщение
Поделиться на других сайтах
В 03.10.2018 в 12:45, i1.nazarov сказал:

такаж проблема, нашли что-нибудь?

Читайте РД 107.2.1002-89.

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Примечание: вашему сообщению потребуется утверждение модератора, прежде чем оно станет доступным.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • denel
      Добрый день! А как произвести репозиционирование зажимов? Пишут g85… а как её использовать? 
    • gudstartup
      если конус хороший в том числе и на оправке и усилие зажима соответствует норме то ничего там болтаться не будет это что касается оправки а инструмент все равно может отгибать
    • Gorich
      @gudstartup Большое спасибо...что уделили мне время...решил проблему...нашел там  вот такое: Ввел команду m22...и магазин уехал на свое место...и дальше все аработало!
    • Gorich
    • Viktor2004
      это усилие зажима пружин. А как при вращении там болтается конус чем померить?
    • gudstartup
      при помощи тестера  например такого это самый простой по простому попытайтесь выдрать оправку ломиком!
    • gudstartup
    • TVM
      Для общего развития интересовался. И на предложение, спроектировать крышечку - там все просто, не ведусь. 
    • Gorich
    • Нанософт разработка
      Одним из эффективных способов осуществления строительного надзора является использование результатов лазерного сканирования с построением 3D-моделей, что дает наиболее полную информацию о строительных объектах с привязкой к пространственным, инфраструктурным и центральным инженерным коммуникациям. Институт «Сибгипробум», активно работающий над совершенствованием мониторинга и созданием цифровых двойников, использует комбинацию технологий «Платформа nanoCAD + ReClouds» как бесшовную инженерную среду для проектирования и для работы с облаками точек. Комплексную поддержку при внедрении программных решений предоставила компания «Бюро САПР» – премьер- и фокус-партнер компании «Нанософт» по направлениям «Конструкции», «Инженерия» и «Землеустройство».   О компании АО «Сибгипробум» – институт, на протяжении 65 лет специализирующийся в области проектирования предприятий лесной и целлюлозно-бумажной промышленности, объектов глубокой химико-механической переработки древесины, а также разрабатывающий проекты экологических и энергетических объектов. В проектной деятельности институт активно использует технологии лазерного сканирования и информационного моделирования. Исходная ситуация ·        Отсутствие возможности оперативного повсеместного контроля строительства на промплощадке. ·        Отсутствие актуальной трехмерной модели объекта, которую в дальнейшем можно было бы сопоставить с облаком точек. ·        Сжатые сроки, которые не позволяли создать трехмерную модель. Задачи цифрового мониторинга ·        Поиск изменений между отчетными периодами. ·        Подсчет объемов монтажа. ·        Поиск пространственно-временных коллизий. Сравнение облака точек в двух отчетных периодах на графике строительства – S-кривой. Красным подсвечено то, что изменено (это было сделано на другой платформе)   Оптимальное технологическое решение можно выбрать в зависимости от степени сложности точечной задачи в рамках цифрового мониторинга. Продемонстрируем это на конкретных примерах. Прикладная задача 1: проверка проектного положения монтируемого оборудования и конструкций. Выбранная технология: Платформа nanoCAD для совмещения 2D-чертежей с облаком точек. Алгоритм работы технологии: загрузка исходного облака точек формата LAS в nanoCAD импортом NPC → создание удобной ПСК для сравнения облака точек в нужном ракурсе → копирование чертежа и совмещение по «точкам доверия» (например, по колоннам здания) → создание сечения → поиск отклонений. Полученный прикладной результат: разрез на определенной отметке показал отклонение по колоннам здания, из-за чего стена построена «криво». Благодаря этим данным авторский надзор перепроверил расчетные значения и скорректировал решения. В результате эту стену пришлось укреплять дополнительными металлоконструкциями. Плюсы и минусы технологии Плюсы: Минусы: ·        не требуется трехмерная модель; ·        простая технология, которую может освоить каждый; ·        низкие требования к аппаратному обеспечению; ·        низкая стоимость контроля проектных решений без выезда на площадку. ·        трудозатратно, если требуется проверить несколько разных разделов в одной точке; ·        проверка происходит в рамках одного сечения; ·        каждый раз в новом месте проверки требуется совмещение чертежа и облака точек.     Поиск отклонений в конструкциях путем совмещения 2D-чертежей с облаком точек в Платформе nanoCAD   Прикладная задача 2: анализ деформации оборудования – цилиндрической печи. Выбранная технология: ReClouds для сравнения облака точек печи с ее 3D-моделью. Алгоритм: загрузка исходного облака точек (в формате LAS) и цилиндра, выполненного в виде 3D-солида, равного диаметру печи → совмещение 3D-моделей → использование команды ReClouds Сравнение → побор опытным путем радиуса отклонения (вылет точки от нормативного положения) → создание градиентного графика отклонений → поиск отклонений. Полученный прикладной результат: выявлены отклонения трубы от нормативного положения: вмятина и провисание. Наглядный способ проинформировать проектировщиков и строителей, на какие участки следует обратить внимание, чтобы принять решения о ремонте, частичной или полной замене. Эффективность использования ReClouds ·        Автоматизация обработки данных 3D-сканирования. ·        Работа в знакомой инженерной среде с интуитивно понятным интерфейсом. ·        Высокая скорость работы. ·        Минимум финансовых и аппаратных ресурсов. ·        Интеграция со специализированными решениями. ·        Гибридность используемых технологий: Платформа nanoCAD и ReClouds позволяют одновременно работать с 3D-моделью, 2D-чертежом и облаком.                                         Анализ деформации цилиндрической печи с помощью ReClouds. Справа красным и зеленым цветом подсвечена сама труба   Отклонения трубы от эталонного 3D-солида: слева видна вмятина, справа – провисание трубы Мнение пользователя Павел Владимирович Коротких, главный специалист – руководитель группы отдела по цифровизации инженерных процессов и данных, АО «Сибгипробум»   «Когда геополитическая ситуация обострилась и были введены санкции, перед нашим институтом, как и перед предприятиями многих других отраслей, встала задача импортозамещения.   Много где возникали сложности, но было очень отрадно знать, что базовое инженерное ПО нам есть чем заменить. Этим ПО стала Платформа nanoCAD, которая оказалась намного большим, чем просто скопированный зарубежный продукт.   Из стандартного функционала хотелось бы отметить, во-первых, Диспетчер чертежа, который позволяет удобно осуществлять менеджмент чертежей; а, во-вторых, базовые операции при работе с облаками точек: импорт/экспорт, настройки визуализации, подрезку, сечения и т.д.   Использование ReClouds – вертикального приложения к Платформе nanoCAD – дало нам расширенные возможности взаимодействовать с облаками точек, при этом оставаясь в единой инженерной среде.   Обнадеживает активное развитие продуктов со стороны разработчика и неуклонно растущее комьюнити пользователей».   О компании «Нанософт» «Нанософт» – российский разработчик инженерного ПО: технологий автоматизированного проектирования (CAD/САПР), информационного моделирования (BIM/ТИМ) и сопровождения объектов промышленного и гражданского строительства (ПГС) на всех этапах жизненного цикла, а также сквозной цифровизации всех процессов в производстве. Миссия компании – формирование условий для массового оснащения российского рынка лицензионными, качественными и доступными отечественными программными продуктами. «Нанософт» помогает своим заказчикам достичь импортонезависимости в области инженерного ПО и нацелена на развитие собственных технологий в фокусе реальных потребностей. Это позволяет гарантированно защитить критически важную ИТ-инфраструктуру, что особенно актуально сейчас, когда западные вендоры уходят с рынка, замораживают поставки ПО и техническую поддержку. Все программные продукты компании включены в Единый реестр российских программ для электронных вычислительных машин и баз данных. Официальный сайт: nanocad.ru.  
×
×
  • Создать...