Исходные данные для …
Исходные данные и комплексный подход
Попробуйте увидеть всю картину сразу, как и из чего состоит изделие, как изделие собирается, как отгружается и как эксплуатируется. Не по частям, а сразу. После некоторой тренировки у Вас получится. Просто соберите все исходные данные.
В наше время процесса больше, чем конечного результата. Правильно организованный техпроцесс, состоит из общеизвестных действий, сбор исходных данных (всех а не частично), во первых. От этого зависит получится ли у Вас с первого раза реализовать задуманное или нет. Применительно к разработке систем управления есть несколько узких мест, где возможен только ручной ввод. Рассмотрим на примере разработки системы управления чем-либо. Любой. Абсолютно любой.
Как Вы яхту назовете..
Конечно систему надо как-то назвать, создать проект, ввести данные о заказчике и прочую проектную информацию. Это исходные данные? Будем считать что да.
Самое главное
- Составить перечень входных сигналов (датчиков, источников исходных данных) и их форматов (уровней, частотности,протоколов, и т д.).
- Составить перечень выходных сигналов и их параметров, протоколов интерфейсов.
- Составить алгоритм обработки входных данных в выходные. То есть зависимость выходных данных от исходных данных.
Приблизительно так
В общем-то это и все что необходимо и достаточно для разработки любой системы и формирования технического задания.
Все эти 2 (или 4) формы могут быть на одной странице или заполняться по очереди. Результатом заполнения этих форм должен быть массив данных в формате json, xml, etc. Этот файл должен быть импортирован в IDE для разработки в визуальном режиме или использован при сборке проекта в командной строке. Собственно первый этап закончен.
О чем часто забывают
Программа сама по себе имеет смысл только в смартфонах, десктопах, и на стороне сервера. В остальных случаях присутствуют компоненты которым не придают должного значения.
Конструктив
Можно сделать программу, изделие надежное и суперсовременное. И все впечатление испортить неподходящим корпусом, некачественной покраской, напечатанными на самоклейке надписями. Сейчас очень просто разработать и изготовить любой корпус, недорого выполнить надписи, например шелкотрафаретом или фотоспособом. Сразу проявляется почерк. Что ни говори, визуальная часть имеет большое значение.
Новая печатная плата или готовый контроллер?
Сейчас выпускается такое количество всевозможных контроллеров и процессорных плат, что несложно подобрать готовые решения. В ряде случаев это оправдано. Стоит того разработка специализированной платы? Начиная с некоторого объема изделий, однозначно можно сказать да. Причина очевидная, плата вместе с компонентами изготавливаются на специализированных линиях, это доступно повсеместно, с достойным качеством. При разработке специализированной платы в подавляющем большинстве случаев можно вообще избежать лишних операций — жгут, ручная пайка, невысокая производительность и человеческий фактор. И себестоимость еще никто не отменял.
Таким образом, после сбора исходных данных и формирования задачи (технического задания) наш процесс разделяется на 3 параллельно потока.
- Разработка конструктивов, если они есть, дизайна, логотипов, надписей и т д.
- Разработка hardware, если у Вас есть замкнутый цикл производства, опытные образцы, они же серийные, без ошибок с первого раза. Так бывает.
- Разработка software, программного обеспечения как заключительный этап.
И далее по техпроцессу уже выходящие за пределы основных этапов разработки важнейшие вещи: документация, руководство пользователя, упаковка, коносамент, и конечно же пиастры.
Таким образом, файлы первой очереди, без которых никак невозможно:
- Исходные данные, предположим в .json что в них должно быть в самом начале статьи
- Файл(ы) печатной платы, допустим .pcb
- Файл(ы) конструктива, например .sld*
- Файл программного обеспечения, пусть будет .bin или .pkg
К файлам второй очереди без которых можно и обойтись относятся например:
- Технологическая карта для pcb. Не всегда нужна.
- 3D модель в сборе. Для проверки правильности крепежных отверстий
- Исходные данные о крепежных отверстиях.
И на заключительном этапе, в третью очередь, в качестве отчетов, рабочий проект по ГОСТу, Архитектура ПО, Руководство пользователя, формуляр, упаковочные документы, документация по сертификации, паспорт, и очень много чего еще. Но это уже другая история.
Таким образом, организовывая техпроцесс исходя из тезиса «необходимо и достаточно» можно получить готовое изделие с первого раза и без дальнейшего исправления и доработок. Доработки возможны только в программном обеспечении, для этого и существует софт.
Далее все в качестве отчета. И в общем-то все файлы должны генерироваться системой разработки. Кроме описанных выше этапов ручного ввода начальных данных, конструктивов , печатной платы и ПО, все рутинное и шаблонное должно генерироваться системой в качестве отчетов. Автоматика должна работать, а люди наслаждаться тем как она работает.
В заключение отмечу что электроника и программное обеспечение сами по себе имеют узкую область применения. Электроника, программируемая электроника всегда чем-то управляет, исполнительными устройствами, машинами и механизмами. Что является неотъемлемой частью системы. И что обязательно следует учитывать, что в системе присутствует еще один важный фактор. Человек. То есть для рассмотрения Вашего изделия целиком и всеобъемлюще, необходимо рассматривать систему как «Человек-система». И автоматика и программное обеспечение может занимать в этой человеко-системе небольшой «объем».