ber2004

Здесь http://sw-specarchive.narod.ru живёт
проект "SW-спец-архив 2006"

(SolidWorks спецификация + архив)

Точнее, его файлы. А обсуждение - на http://sapr2000.ru/invision/index.php?showforum=25

Спасибо всем принимающим участие в родах, и особенно Алексею, без которого этот проект не состоялся бы.

Скачать полную версию:

Версия 03 от 12.12.2005

http://sw-specarchive.narod.ru/ber2004_SW-SpecArchive_2006_v.03_12.12.2005.doc (141 kB)

http://sw-specarchive.narod.ru/ber2004_SW-SpecArchive_2006_v.03_12.12.2005.rar (30 kB)

Кроме того:

файлы, связанные с моей работой в SolidWorks:

(шаблоны спецификаций, шрифты, руководящие материалы и т.п.)

http://sw-specarchive.narod.ru/files

проект "SW-спец-архив 2006"

(самые третьи наброски)

1. Преамбула. Для кого это всё?

Конструкторы, работающие в одиночку, при выпуске РКД, как правило, довольствуются штатными средствами SolidWorks, AutoCAD и т.д. В больших фирмах типа судостроительного завода - ставят могучую PDM/PLM-систему, иначе нельзя. А вот в промежутке...

Маленькие КБ с числом конструкторов 3...10 на сегодняшний день находятся у разбитого корыта. Штатных средств уже не хватает, а могучие системы не по карману. Начальство ещё спокойно, «ведь как-то справляемся», а ты с болью видишь, как очень скоро эта убогая Excel-евская табличка, гордо называемая «архивом» рухнет под накопившимися ошибками...

Именно для таких небольших, обычно небогатых, КБ (как моё) и задуман этот проект. Для тех, где все «по-взрослому», где есть архив, где производство работает по учтенным копиям, где по изменениям выпускают извещения, где необходимо взаимодействие сотрудников (и приходится разруливать связанные с этим проблемы) и т.д. Для тех, кому надо попроще и без спец. обучения, чтобы «пусть некрашеное, лишь бы ездило». Для тех, кому некогда «внедрять», а надо просто работать.

Подойдет ли эта идеология для больших предприятий? Может быть. Надо бы попробовать. На первый взгляд масштабируемость присутствует.

В состав проекта включено только то, чего не хватает. Всё, что можно сделать штатными средствами - ими и делается. Это не «как в ХХХ, только попроще», а попытка осмыслить реальность и построить «с нуля» разумную несложную систему.

Решаются основные задачи:

· Генерация спецификаций (на основе свойств моделей для SolidWorks и аналогичных пакетов. Для ACAD и т.п. - на основе свойств чертежей, в крайнем случае - пишется вручную) в простом формате, пригодном для полуавтоматической обработки.

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

· По информации из базы генерятся отчеты разного вида: от ведомости спецификаций и ведомости покупных до схемы деления. Т.е. генерится «начинка» для последующего оформления в виде соответствующих документов по ЕСКД. При наличии в спецификациях признаков «сдано в архив», «изготовлено» и т.п. - можно генерить отчеты для управления процессом проектирования («текущее состояние дел») и т.п.

· Базу (любую из баз) можно просматривать с различными фильтрами, решая задачи «куда входит эта деталь», «какие детали входят в эту сборку», «сколько нужно АМг6 на все изделие» и т.п. По сути, это - тоже отчеты, только другого вида, и для применения не в РКД, а в оперативном управлении.

· Что-нибудь ещё?

В качестве исходных положений:

· Поток информации «снизу вверх», генерация информации на уровне разработчиков узлов, выше - только обработка

· высокий уровень автоматизации (не набирать ручками дважды одно и то же),

· высокая автономность информации (отсутствие взаимовлияния на уровне исходников), что повышает надежность хранения в условиях беспризорности,

· Что-нибудь ещё?

Хотя ниже многое написано в настоящем времени, пока это именно проект, только ТЗ на программирование. Кто возьмется?

Продолжение и подробности (30 kB)

2. Концепция е-архива

2.1. Кто постановит задачу лучше?

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

2.2. Е-спецификация - как основа информации об изделии

По ЕСКД основным документом на сборочную единицу (вплоть до всего изделия) является спецификация. Генерить которую хотелось бы автоматически (в основном) по модели SolidWorks, но которую часто приходится править вручную (в сложных сборках всегда) - поскольку некоторые сущности не отражаются в модели (провода, например, когда "электромонтаж условно не показан"), или модель неполна/условна и т.п.

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

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

Чтобы достичь вышеупомянутого, ввожу (26.11.2005) понятие "е-спецификация". В "е‑спецификации" в простой табличной форме отражена вся значимая информация из обычной спецификации, но без оформления, разбиения на страницы и т.д.. Состав столбцов может и должен быть дополнен необходимыми (материал, масса и т.д.). "Е-спецификация" является простым текстовым файлом с разделителями, с расширением *.sldspa (т.е. "SW-спец-архив"). Формат уточним позже, видимо вначале - заголовок, относящийся к сборке (содержимое штампа) и далее - табличка по деталям. Возможно применение формата *.dbf, но душа пока не лежит и ограничения там есть.

Поскольку к тому же в чертеже SW нужна спецификация "на листе" для простановки позиций (так ли это?) - наша "е-спецификация" должна храниться в файле сборочного чертежа и отображаться и обрабатываться там же. По сравнению с "родной" отличается расширенным функционалом и неизменяемостью (кроме как вручную). А е‑спецификацию "в файле" (для использования в архиве и др.) получать экспортом.

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

Продолжение и подробности (30 kB)

2.3. Е-архив - как отражение, а не хранилище

При складировании файлов в архиве неизбежно наступает диалектический переход количества в качество и появляется это страшное... БАЗА ДАННЫХ.

Базы данных я не боюсь, я решительно против неё («базы данных» в общепринятом смысле).

Для меня искомая идеальная база - не хранилище информации (как реализовано у других), а отражение, зеркало, копия для быстрого доступа к информации. Храниться информация (по моему плану) должна в спецификациях. Это на мой взгляд полнее отвечает сути "вещественных" процессов. Распределённое хранение информации обеспечивает помехоустойчивость, защиту от дурака, масштабируемость и проч.

Единая база (как хранилище) - прежде всего признак работы "сверху-вниз" от управления проектом, и во-вторых - масштабный фактор: при больших объемах информации - время отклика можно сделать приемлимым, только если все заранее разжевать и эту кашицу по полочкам разложить. Отсюда SQL и т.д. У нас управление проектом - на уровне план-графиков, и электронным станет нескоро (никогда?), а масштаб - небольшой. Кроме того осваивать систему никто не прикажет, а убедить можно только при условии простоты освоения и наглядности.

Но когда информация попала в базу - обрабатывать её можно вполне традиционными способами во вполне традиционных целях.

По информации из базы генерятся отчеты разного вида: от ведомости спецификаций и ведомости покупных до схемы деления. Т.е. генерится «начинка» для последующего оформления в виде соответствующих документов по ЕСКД. При наличии в спецификациях признаков «сдано в архив», «изготовлено» и т.п. - можно генерить отчеты для управления процессом проектирования («текущее состояние дел») и т.п.

Базу (любую из баз) можно просматривать с различными фильтрами, решая задачи «куда входит эта деталь», «какие детали входят в эту сборку», «сколько нужно АМг6 на все изделие» и т.п. По сути, это - тоже отчеты, только другого вида, и для применения не в РКД, а в оперативном управлении.

Продолжение и подробности (30 kB)

2.4. «Если у вас нету базы - её вам не потерять...» (аргументы против базы-хранилища)

Из переписки:

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

>>Тем более, что это вся база данных - это всего лишь один единственный файл MS Access (.mdb)

Вопрос этот важный. Только сегодня на меня набросился один человек, очень уважаемый, но слишком энергичный, чтобы быть вполне рассудительным. Требовал базу. Но ведь никакие резервные копии не спасут, если что-то собьется. И уже испорченная информация будет исправно дублироваться и бэкапиться, поскольку нет проверки на "испорченность" информации по давно сданному в архив узлу. Например, у нас коллега мой делает резервное копирование рабочих файлов наших и архива на CD-RW. 2...3 последовательных версии, потом самую старую затирает очередной. И если ошибка (в том числе человеческая) прокралась давно, например, в версию четвертую от конца - то все более свежие - испорчены, а более старой нет.

Напротив, если при распределенном хранении испортилась одна спецификация из 500 - это лишь один файл, его недолго восстановить по бумаге. (У Вас безбумажная технология? - тогда мы идем к Вам!)

Если нашлись погрешности в базе (небольшие ;-)) кто возьмется утверждать, что там нет и других погрешностей? ненайденных? и что их нет в резервной копии? Они ведь не найдены, даже неизвестно, что искать, что проверять...Я вот в нашей "базе" находил и очепятки и заведомо неверную информация, внесенную "по договоренности". Это находилось по случайности, просто я прицельно интересовался конкретными узлами. А так - проконтролировать некому и нечем. При распределенном же хранении инфы когда разработка узла закончена - вся информация в одной папке. Она не изменяется , точнее изменяется по извещениям, документально подтверждающим что и когда и кто. Считаешь md5 или CRC, ставишь "только для чтения" и спишь спокойно. Контроль неизменности гораздо проще чем контроль безошибочности. А на базу и "только для чтения" нельзя и md5 смысла не имеет...

Это не исключает «базы», это только меняет источник информации при неизменном количестве её. Я ручками работаю не с единым файлом базы, а с локальным файлом спецификации. А база генерится. (вот и вся разница). Дальше одинаково - поиск, просмотр, печать отчетов... И при переходе на Linux например ее недолго перегенерить, а вот с Access-овской - возможны варианты... Оговорюсь, что все мои рассуждения - именно для "маленького" КБ, где в этих вопросах - самообслуживание и личная ответственность (если не сказать колхоз и зоопарк и цирк только что уехал, не всех взяв с собой :-)). Большая организация (с которыми ты сейчас, как я думаю, имеешь дело) может оплатить программистов они сделают систему с ИИ и пятикратным резервированием и т.д. Тщательно продуманная избыточная информация, перекрестные ссылки, "двойная запись" как в бухгалтерии... Другое качество, но и другая цена. Т.е. мой подход в том , что в разных условиях - разные решения. В организациях иерархических, где можно приказать, где IT-шник на окладе и не один - там один подход, у нас другой. У нас некогда и некому.

Продолжение и подробности (30 kB)

2.5. «Будь проще!» или Цена вопроса

2.5.1. Малая трудоемкость

Решение должно быть простым и в программировании и в отладке и в эксплуатации. Сложные решения маленькой организации просто не потянуть!

Из переписки:

>>Меньше всего я сейчас ориентируюсь на цену. для меня результат - это функционал...

Под ценой я имел в виду, что автоматизировать работу одного человека ценой работы пятерых программистов - нелепо. А автоматизировать работу 50-ти ценой работы тех же пятерых - выгодно. У меня маленькая организация, иначе поставили бы СмартТим и не парились. Масштабный фактор. Тебя не волнует трудоемкость твоего проекта, потому что это хобби и ностальгия, а у меня - производственная необходимость. Без обид?

2.5.2. «Неавторская модернизация»

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

«Ремонтопригодность» всего комплекса опять таки повышается, когда вся информация программой только обрабатывается, а хранится децентрализованно, распределенно по файлам. Причем хранится максимально стандартными средствами. Так основной массив информации хранится в свойствах деталей, сборок и чертежей. Если программа делает в основном то, что можно сделать штатными средствами (но удобнее) - значит её легко заменить на другую или в крайнем случае, на время «ремонта» обойтись штатными средствами. Такой подход - надежная защита от программных сбоев, несоответствия версий и т.д. По этой же причине все "нештатные" файлы с данными - в простом текстовом формате. (Отсюда и растут некоторые ноги е‑спецификации)

2.5.3. Открытый код?

Из переписки с программистом:

>Естественно залезть внутрь файла ты не сможешь, естественно ты без

>оболочки сам ничего не изменишь, - извини, а зачем тебе лазить туда без оболочки?

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

Ведь у нас все по-взрослому? Ты ведь не купишь фотоаппарат, пленка к которому в нестандартных кассетах, и притом ее в твоем городе не продают? Даже если он хорош. (исключаем случай, когда ты из этих, которым на заказ возят и даже на заказ делают)

Мне приходится думать о будущем, и это нормально. Любой продукт не идеален, и без поддержки он умирает (Где сейчас Нортон Коммандер 5.0 ? Там же, где все файловые менеджеры, не поддерживающие длинных имен и ftp). Любая заковыка, ошибка в коде, а ты занят, заболел, умер... - и тысячи людей в нескольких русскоговорящих странах будут горько плакать? На производстве так не бывает! Так не должно быть! Если ты не фирма масштаба Autodesck, которая вряд ли сгинет бесследно (и то, некоторые соизмеримые уже почили, затоптанные нынешними монстрами. Были большие траблы с переходом на другую платформу) - единственно возможный вариант - открытый код. Иначе у твоей работы не будет юзеров кроме тебя.

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

Т.е. по сути идеал для меня - "доступность к неавторской модернизации". Т.е. не только открытость кода, но и открытость алгоритмов, доступность технических средств для модернизации и невысокий уровень потребной квалификации. Пусть тебя всё это не смущает. Давно известно, что сделать простое труднее, чем сделать сложное. У меня был показательный опыт, когда я узел делал трижды. Каждая следующая версия была в 1.5 раза компактнее и с меньшим количеством деталей. Я был рад (но уже потом, не заранее), что критики настояли на переделке. По счастью начальство было толковое и дало возможность переделывать, не стало сразу в железо гнать. Получился перерасход на мне, но он окупился экономией в производстве и лу’чшими потребительскими качествами (с этим узлом общались непосредственно пользователи нашего агрегата).

Т.е. простота, на которую я тебя (и себя) настраиваю - это признак высокого мастерства программиста, и достичь ее труднее, чем зафигачить по шаблону даже самую сложную базу. (кстати и на SW98+ я перешёл с MDT2..3 из-за простоты! В SW ткнул мышкой в грань нажал кнопку - и строишь эскиз, MDT2..3 - восемь нажатий мышкой в разных местах, и при этом создается вспомогательная плоскость, которая потом живет своей жизнью и связь с гранью может потерять)

Продолжение и подробности (30 kB)

3. Программный комплекс «SW-Спец-архив»

3.1. Состав комплекса

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

· Генератор спецификаций (он же менеджер свойств файлов)

· Менеджер баз данных (он же генератор отчетов разного вида)

· Менеджер файлов - организация совместной работы через управляемое разделение прав на файлы и контроль изменений.

· Что-то ещё?

Генератор спецификаций может быть автономным приложением, остальное напрашивается какой-то единой оболочкой с плагинами. Впрочем и спецификатор может быть плагином там же. Разделяемые элементы: дерево папок/файлов и т.д.

Продолжение и подробности (30 kB)

. . . . . . . . . . . . . . . . .

Прочёл? Не сочти за труд, черкни пару строк на

. . . . . . . . . . . . . . . . .

Всё это и многое другое - в файле:

http://sw-specarchive.narod.ru/ber2004_SW-SpecArchive_2006_v.03_12.12.2005.doc (141 kB)

http://sw-specarchive.narod.ru/ber2004_SW-SpecArchive_2006_v.03_12.12.2005.rar (30 kB)

Download Загрузить:

файлы, связанные с моей работой в SolidWorks:

(шаблоны спецификаций, шрифты, руководящие материалы и т.п.)

http://sw-specarchive.narod.ru/files