Целью данной статьи ни в кой мере не является продвижение или рекламирование Altium Designer, который и так хорошо известен среди профессионалов данной области. Мы проведем своего рода экскурсию вглубь проекта и познакомимся с особенностями его реализации в контексте сложности задачи и масштаба реализации. Это будет особенно полезно для начинающих разработчиков, а также специалистов, интересующихся большими во всех смыслах системами (а не только большими данными).
Давайте сразу оценим масштаб системы в контексте её функционала. Опишите, пожалуйста, основные функциональные модули или подсистемы. Это очень важно, т.к. термин CAD (computer aided design) имеет достаточно широкое значение – так можно назвать и простое приложение-«рисовалку», и интеллектуальную САПР. Что умеет делать Altimum Designer?
Инженер получает или же формулирует спецификацию устройства, начиная от условий, в которых оно должно работать, заканчивая элементной базой, которую планируется использовать. Сейчас очень часто разработка ведется от микропроцессора — выбирается чип, решающий необходимую задачу, и под него проектируется обвязка. После этого создается библиотека используемых компонентов, набрасывается логическая/принципиальная схема в редакторе схем. Здесь же задаются уточнения и ограничения, которые могу влиять на то, как плата будет «разводиться» физически. Могут выполняться различные виды анализа — целостности сигнала, моделирования схемы. После этого начинает создаваться печатная плата, т.е. задается кол-во используемых слоев согласно спецификации, размещаются компоненты, определяются дорожки, которые передают сигнал, подводят питание и т.п. Т.е. формируется уже физическое представление платы. После чего генерируется документация, формируются файлы, отправляемые на производство/печать плат, строится список используемых компонентов для сборочных конвейеров.
Одно из преимуществ АД то, что все вышеперечисленные операции выполняются в одном продукте в очень тесной интеграции друг с другом.
Основные функциональные блоки системы:
- платформа;
- редактор схем;
- управление библиотеками компонент;
- редактор печатных плат;
- ядро 3D режима;
- анализ целостности сигнала;
- модуль генерации выходных файлов;
- модули импорта/экспорта — начиная от 3D моделей, заканчивая данными для симуляции во внешних системах
Можно ли сказать, что каждая из функциональных подсистем представляет собой достаточно изолированные модули. Так ли это? Если так, то как реализованы модули? Это dll-плагины к некому ядру? Это равнозначные приложения? Какой механизм обмена данными между ними?
Как и большинство крупных систем, Altium использует модульную архитектуру. Есть платформа, обеспечивающая базовую инфраструктуру (документы, настройки, подсистема сообщений и т.п.) и модули, реализующие функционал. В последних версиях каждый модуль — изолированная dll, предоставляющая набор интерфейсов. Интерфейсы не COM-совместимы, но интероперабельны. На этой платформе построено несколько продуктов, но самый крупный — AltiumDesigner.
Чуть подробнее о том, как сочетаются модули. Есть какое-то внутреннее API? Весьма вероятно, что в Altium каждая подсистема разрабатывается отдельной командой. Есть у вас обобщенное представление? Или некие протоколы обмена между модулями? Есть ли сетевое взаимодействие?
Да, конечно есть API используемое внутри. Основа — интерфейсы с некоторыми ограничениями по используемым типам. Довольно широко используется система команд/сообщений.
Учитывая то, что помимо Altium Designer (AD) в стеке решений компании есть достаточно широкий набор вспомогательных продуктов, начиная от сервера лицензий и заканчивая инфраструктурой обеспечивающей экосистему Altium.Live, сетевого взаимодействия много. Активно используются веб-сервисы. Для внутренних продуктов – это чаще всего SOAP протокол, с внешними сервисами? в последнее время — REST.
Как организовано хранение проектов?
Здесь все достаточно просто, есть несколько SVN-репозиториев, разделенных по прикладным областям: платформа, ядро продукта, расширения, веб-проекты. Управление задачами в Assembla, активно используем Google docs.
Есть несколько внутренних вспомогательных сервисов — сбор «креш-репортов», «билд-система», система запуска тестов на «тест-фарме».
Когда мы говорим о полномасштабной среде, возникают простые, но интересные вопросы. Сколько пунктов меню в главном окне системы? Сколько окон в приложении? Понятно дело, никто специально не считает, но просто интересно. Это как «на постройку телебашни пошло столько-то миллионов заклёпок или болтов». Как у вас с такими формальными параметрами?
Честно говоря, мало кто занимается подобными подсчетами. Хотя об этом могут знать коллеги, занимающиеся документацией — им все эти диалоги приходится поддерживать в актуальном состоянии :)
Поиск dfm-файлов по двум основным репозиториям дает числа ~500 для платформы и ~1800 для основного продукта. Кол-во пунктов меню как-то уж совсем сложно вычислить, тем более оно динамическое, и зависит от открытого документа, режима работы и т.п. Но их действительно много :)
В базовой конфигурации порядка 150-200 dll-модулей, в базовых репозиториях около 500 dpr-проектов, полный «билд» продукта занимает 40 минут (правда это действительно полный, результат такого «билда» становится доступен пользователям в системе обновлений).
Можно представить какой-нибдуь скрин-шот окна системы с загруженной схемой. Это – типовое окно объектной САПР? Главное рабочее графическое поле, панель инструментов, редактор свойств объектов? Или есть некие особенности?
В основном работа ведется с логической схемой проекта (первый скриншот) и уже его физической реализацией (второй скриншот). Есть конечно еще множество других областей, но это ключевые.
На втором скриншоте (ниже) — 3D представление гибко-жесткой платы. Сам дизайн обычно ведется в 2D режиме.
Использовали ли вы стандартные компоненты Delphi или для повышения уровня эргономики интерфейса использовали дополнительные библиотеки?
Из визуальных – довольно широко используются компоненты DevExpress и DreamControls, есть достаточно много самописных элементов управления.
модель рисования – использовали «канву» или какую-нибудь GPU-based библиотеку (OpenGL, DirectX)?
Сейчас для схем — GDI/GDI+, для PCB — DirectX.
Насколько открыта система? Можно ли создавать свои пользовательские плагины?
Она была достаточно открыта ранее, сейчас существует достаточно много расширений, чаще всего интеграционного характера. А в последних версиях на это сделан акцент — у нас появилось SDK для Delphi, C++ и С#. В ближайшие дни выходит версия DeveloperEdition, которая сделает разработку расширений еще проще.
Есть ли механизм пользовательской автоматизации? Какие-нибудь скрипты, макросы, внутренний язык программирования?
Да, есть, достаточно популярный у пользователей, Delphi/Basic/Java-script. Используется как для написания расширений, так и для повседневной работы, в частности для задания сложных фильтров по объектам.
Поговорим об истории развития. С чего начинался проект?
Компания, как и продукт началась достаточно давно, в 85-м году когда появились доступные персональные компьютеры и назрела необходимость автоматизации создания печатных плат. Одной из первых компания создала ECAD под Windows, тогда это был не такой очевидный шаг, как кажется сейчас. Дальше были выход на австралийскую биржу, череда поглощений компаний и технологий, построение интегрированного стека технологий для разработки электронных устройств.
С какой версии Delphi и по какую ведется разработка Altimum Designere-а? Понятно, что такой масштабный проект сложно мигрировать, но были ли успешные попытки?
Если я не ошибаюсь, первые версии продукта были созданы на TurboPascal, далее череда версий Delphi начиная с 3-ей. На текущий момент это Delphi 2010. Миграции обычно происходили тогда, когда это было оправдано с прагматичной точки зрения — появлялись необходимые технологии, исправлялись критические ошибки. Любое, даже незначительная модификация системообразующих классов заставляет сильно призадуматься и очень взвешенно подойти к решению, вплоть до весьма точно расчёт трудозатрат. Примем во внимание, что есть ещё и сторонние библиотеки. Пока мы не спешим с переходом на последнюю версию.
Но помимо Delphi использует довольно много языков и сред, к примеру часть модулей реализованы на C++ и С#, для части веб-сервисов и приложений используется Morfik.
Как организована архитектура основных модулей? Это классические варианты типа «форма-элемент управления-действие-процедура отклика» или есть более изощренные техники типа разделение модели и интерфейса?
В таком большом проекте есть множество подходов. Один из ключевых — разделение описания команд и кода их исполняющего. Основные панели команд и меню описаны во внешних, конфигурируемых файлах, для документов есть более-менее четкое разделение модели и отображения, вспомогательные изолированные диалоги обычно реализованы классически форма-событие.
Интерфейс среды в основном статический или есть динамический механизм генерации интерфейса пользователя в зависимости от внешней конфигурации?
Часть интерфейса зависит от того какой документ открыт (к примеру для PCB и BOM набор команд и меню отличает кардинально), от того какой функционал доступен с активной лицензией. Т.е. какой-то базовый каркас, обеспечиваемый платформой, неизменен, остальное определяется режимом и логикой работы модуля.
Какие сложные, научные с элементами искусственного интеллекта или просто интересные алгоритмы применяются в системе?
Не совсем уверен в применении AI, но есть несколько областей в которых алгоритмическая база довольно сложная, особенно в области PCB и симуляции. К примеру авторазводка плат — область очень емкая с точки зрения алгоритмики. При ее реализации приходится решать не только задачу размещения дорожек в пространстве (сейчас большинство плат многослойные, и трек может менять слои), но и учитывать громадное кол-во ограничений, задаваемых пользователем — минимальное расстояние между дорожками, импеданс дорожки, “шумность” получаемой топологии на высоких частотах и т.п… Полноценно эта область у нас еще не решена.
Есть ли возможности по оптимизации, например, общих размеров печатных плат и конструктивных элементов? Многопараметрическая оптимизация? Динамическое задание ограничений?
Откровенно каких-то оптимизаций я особо не припоминаю, особенно по размерам. Я бы даже сказал, что размеры часто приходят “снаружи” — в виде спецификации, механической модели уже существующего устройства, размера используемого чипа, интерфейсного разъема и т.п.
Очень часто проект может начинаться с задания множества ограничений, т.н. constraint driven desing. Инженер определяет ограничения, иногда достаточно сложные, а продукт помогает их исполнять или запрещает нарушать. Например, одна из простых проверок — ширина дорожки между определенными компонентами или допустимые углы при разводке ВЧ-трактов.
Каковы возможности по подключению внешнего производственного оборудования к системе? Можно ли использовать систему в составе стенда, когда на вход инженер подает формальное описание задачи, а на выходе – уже готовая схема, реализованная «в железе»?
Производственного — скорее нет, чем да. Это все же область хоть и смежная, но далекая от той, на которой фокусируемся мы — дизайн и разработка. Управлять современной сборочной линией, когда автомат на готовые платы наносит припой, размещает компоненты, а затем «запекает» плату согласно техпроцесса достаточно сложно, и совершенно не пересекается с разработкой самой платы. Хотя поддержка стадии изготовления, безусловно, есть, это одна из важнейших частей процесса — экспорт и подготовка данных для изготовления плат, для сборочного производства, для тестовых стендов и т.п.
Из подключаемого оборудования можно упомянуть Nanoboard, устройство используемое для разработки с использованием программируемой логики (FPGA/ПЛИС).
Думали ли вы о реализации некого мобильного front-end-а? Известно, что для многих CAD-систем уже есть мобильные варианты клиентских рабочих мест. Их полезность пока недостаточно очевидна, но, возможно у вас есть своё видение применимости мобильных приложений в рамках больших CAD-систем или даже САПР-ов?
На текущий момент планов таких нет. Как вы сами заметили, не совсем понятна цель и необходимость в них. Для работы их особо использовать не получится, как замена бумажных чертежей в MCAD — тоже…
В компании есть отделы, занимающиеся мобильной разработкой, но это отдельное направление в соседней области, не связанной непосредственно с AD.
Могу предположить, что у вас очень развитая объектная структура. Используете ли вы графические нотации для взаимодействия между разработчиками? Или квалификация программистов такова, что существующее распределение по зонам ответственности и функционалу модулей позволяет использовать исходный код единый источник знаний о системе?
Нет, графических нотаций не используется. Как показывает практика в нашем случае эффективнее непосредственная коммуникация и достаточный уровень квалификации разработчиков.
Чем сложнее система, тем жестче требования к тестированию, особенно, регрессионному. Как у вас налажен данный процесс? Автоматические тесты, ручные тесты, соотношение между разработчиками и тестировщиками?
Хотя у нас есть и автоматическое тестирование покрывающее ключевые области, ручное регрессионное тестирование, развитое бета-тестирование, на мой взгляд, тестирование одна из областей, в которой мы могли бы улучшить ситуацию. К примеру, одна из проблем, которые мы пытаемся сейчас решить — это вовлечение QA инженеров на ранних стадиях разработки.
Какова кадровая политика компании Altium? У вас достаточно закрытая команда? Или вы всегда открыты и готовы принять на работу достойного специалиста?
В этой области компания более, чем открытая. Насколько я знаю, в текущий момент мы активно ищем разработчиков высокой квалификации в киевский и шанхайский офисы. Кстати забавный момент — так вышло, что значительную часть ядра R&D нашей австралийской компании сейчас составляют русскоязычные инженеры.
В первую очередь вы расширяете штат за счет профессионалов или есть вакансии для начинающих, кто только начинает строить свою карьеру в области разработки ПО?
Обычно в компанию приходят разработчики или с хорошими навыками и опытом или обладающие какими-либо уникальными компетенциями. Начинающим влиться в ритм и задачи достаточно сложно.
Если вы приглашаете уникальных специалистов с знаниями, навыками и опытом, готовы ли вы платить зарплату выше среднерыночной?
Да :).
Все же Альтиум — это продуктовая компания, и от того, кто работает над продуктом зависит очень многое.
Чтобы работать в Altium на позиции разработчика, что нужно знать помимо Delphi? Нужно быть «электронщиком», родившимся с «паяльником в руках»? Или нужно очень хорошо знать математику и теорию САПР? Или просто нужно быть грамотным программистом с хорошим опытом решения разнообразных задач?
Нет, не обязательно для работы в нашей компании нужно было родиться «с паяльником в руках» :)) Безусловно знание электроники или математики для некоторых направлений это плюс, но не обязательное требование — круг задач с которыми мы сталкиваемся очень широкий.
Какова стратегия развития продуктовой части? Что сейчас является приоритетным направлением? Повышение уровня автоматизации? Расширения функционала? Попытка войти в смежные области, например, проектирование других элементов сложных технических систем?
Есть несколько направлений, в основном они нацелены на расширение занимаемой доли на рынке ECAD систем. Т.е. мы вряд ли будем двигаться в сторону механических CAD, кроме как расширяя интеграцию с существующими продуктами, но наверняка будем улучшать, к примеру, возможности проектирования плат в 3D.
Традиционный вопрос. Что можно посоветовать начинающим программистам, которые хотят дорасти до уровня профессионально разработки, чтобы быть, к примеру, востребованным компанией Altium?
Ответ в общем случае здесь универсален — набираться опыта, учиться решать задачи, иметь хорошую техническую базу. Есть несколько открытых ECAD проектов, участие в них может быть очень полезным.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.
Комментариев нет:
Отправить комментарий