Самарский портал "Технологии, компьютеры"

Главное дело моей жизни. Часть 1.

НА КРЫЛЬЯХ

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

Кроме идеи о том, что ставить задачи и принимать работу должны предметные специалисты, у меня была не менее революционная по тем временам идея, что и работать за терминалами тоже должны они, а не программисты или так называемые операторы ЭВМ. Поэтому я договорился о том, чтобы к нам в конструкторский зал провели кабель и поставили терминал от СМ ЭВМ. Показал сотрудникам игру Тетрис, а потом перепрятывал эту программу по разным папкам (директориям), чтобы у них был стимул к освоению операционной системы. Напоминаю: в качестве интерфейса была только командная строка.

Установка терминала имела одно неожиданное для меня самого последствие. В патентном отделе завода работала Лидия Ивановна Петина, которая помогала мне с оформлением заявок на изобретения. По какой-то причине её перевели к нам в КБ, и сделали это несмотря на то, что чертить она абсолютно не умела. Уволить Лиду у высокого начальства рука не поднималась, и её футболили из одного бюро в другое до тех пор, пока она не осела у меня. Текстовый редактор в составе системного софта на СМ ЭВМ присутствовал (надо же программистам как-то писать свои программы), но пригоден ли он для разработки текстовой документации, я не знал (тогда я вообще мало что знал, но остальные конструкторы не имели и таких знаний). К моей огромной радости Лида текстовый редактор освоила, и из обузы превратилась в ценного кадра – все руководства по эксплуатации и прочие текстовые документы теперь были на ней. Конструктора освободились от нелюбимой работы, к тому же любые правки в документы вносились мгновенно, и нам не надо было обращаться в машбюро. Если кто не знает, все пишущие машинки стояли в специальном помещении и на них работали специально обученные люди, на выходные 1-й отдел это помещение опечатывал. Видимо считалось, что любой, кто дорвётся до пишущей машинки, немедленно начнёт печатать на ней антисоветские листовки.

КОПАЕМ ГЛУБЖЕ

Внезапно обнаружилась неприятная вещь: все компоненты гидросистем с их характеристиками были намертво зашиты внутрь программы, они не были видны пользователю, и тем более пользователь не имел никакой возможности их редактировать, удалять и добавлять. И тут на сцене появился Крапивин. Так это, говорит, тебе не просто программа, тебе база данных нужна. И дал почитать книжки по теории реляционных баз данных, которые перевернули моё сознание.

На самом деле теория реляционных СУБД, это не про ИТ, не про программирование, а про мировоззрение. Обычно мы все структуры представляем себе в иерархическом виде, потому что только так можно отобразить их на бумаге. Например, структурировать любое изделие: самолёт, автомобиль, велосипед. То же с классификацией, будь это животного и растительного мира Линнея, или система УДК, используемая, например, в библиотечных каталогах. Иерархическая структура вызывает большие проблемы, но пока не появились ИТ с ними мирились, поскольку никакого «бумажного» решения у них не было. Заключаются эти проблемы в том, что, предметного библиотечного каталога (той самой системы УДК), зачастую одно и то же произведение можно отнести к нескольким категориям. Например, и к детской, и к научно-популярной, и детективной литературе, и к фантастике, и к юмору. А ещё оно может быть написано как прозой, так и стихами, или написано прозой, но содержать в себе некоторое количество стихов. И тогда при построении иерархической системы, каковой является УДК, перед разработчиками встанет вопрос: сначала разделить литературу на детективы и фантастику, а уже потом на детскую и взрослую, или сначала на детскую и взрослую, а уже потом каждую ветку на детективы и фантастику? При этом понятно, что любое решение будет, мягко говоря, кривоватым.

Но если на это же самое посмотреть как на реляционную базу данных, всё становится простым и логичным. Каждому литературному произведению можно присвоить любое количество реквизитов, и они никоим образом не мешают друг другу. Можно указать и рекомендованный возраст для прочтения, и количество символов в тексте, и время действия – что угодно. А потом фильтровать по любой комбинации из этих критериев. Но это ещё не всё. Библиографическая база данных состоит из таблиц, и таблица произведений только одна из них. Можно (точнее, необходимо) создать таблицу авторов: ФИО, дата рождения, страна. Потом таблицу автор – произведение, чтобы одним нажатием кнопки получить список того, что он написал. Или другим запросом – с кем он соавторствовал. Разумеется, необходима таблица книг (томов) в которых опубликованы произведения: из собраний сочинений, сборников. Если это переводная литература, то и переводы. И есть целая наука о правильном составлении этих таблиц, называемая приведением к нормальным формам.

Но меня, конечно, интересовало использование баз данных в конструкторской работе. Тут и пришло осознание того, что спецификация в ЕСКД не просто так названа основным конструкторским документом. Конструктора ведь как привыкли: сначала разрабатываем сборочный чертёж, это процесс творческий, и именно на сборочном чертеже мы видим будущее изделие. Параллельно делаем расчёты, подбираем материалы, определяем допуски. Здесь раскрывается талант и квалификация конструктора, работает фантазия. Это захватывающий процесс, он не отпускает ни днём , ни ночью: некоторые решения приходили ко мне в самых неподходящих для этого ситуациях. А потом идёт скучная рутина: простановка на чертеже позиций и в соответствии с ними составление перечня того, из чего эта сборочная единица состоит: работа формальная и никакого таланта не требующая. Однако именно комплект спецификаций представляет собой скелет изделия, не самую интересную часть документации с точки зрения инженера, но основу его информационной модели. При этом если бумажный (а какой же ещё?) комплект спецификаций одного изделия представляет собой иерархию, то весь конструкторский архив забитый в реляционную базу, приобретает принципиально новое качество. Я тогда назвал это двунаправленными деревьями. Дерево вниз – это классическая иерархия спецификаций в направлении «что входит» в каждую сборочную единицу. В частности, по нажатию одной кнопки волшебным образом появляется дерево вверх: информация о том, куда входит каждая деталь или сборочная единица, то, чего на бумаге конструктор увидеть не мог. То есть, теоретически мог, но для этого ему потребовалось бы перерыть весь архив от начала до конца, поскольку специального конструкторского документа, содержащего такую информацию, не существует. А перепахивать весь архив ради получения такой информации, разумеется, ни один вменяемый человек не будет. Но, может быть, такой потребности и не существует?

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

Представьте себе, что в Вашем изделии есть дверь и дверная ручка. Неважно, что это за изделие: шкаф, автомобиль, самолёт. Ваш коллега при разработке своего изделия подглядел эту ручку и использовал в своём изделии. Прошло время, и Вы стали получать жалобы, что ручка слишком маленькая, крепление слишком слабое. Вы увеличиваете ручку, усиливаете крепёж, проводите извещение об изменениях, что с такого-то серийного номера изделия на него будет устанавливаться изменённая ручка. Заодно, разумеется, проводите соответствующие изменения в двери: увеличиваете расстояние между отверстиями, а также их диаметр – чтобы в них пролезли увеличенные винты. При этом в общем случае ни Вы не знаете, что Ваш коллега использовал в своём изделии Вашу ручку, ни Ваш коллега не знает, что Вы провели изменения. Результат очевиден: в какой-то момент Ваша изменённая ручка перестанет подходить к его не изменённой двери.

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

А вот система, построенная на реляционной базе данных, эту задачу решает легко. И начинается она с двух взаимосвязанных таблиц: об изделии и о составах изделий. Первая таблица (здесь даю её не полностью) содержит поля «конструкторское обозначение» (оно уникально), «наименование», «вид изделия» (деталь, сборочная единица, комплект, комплекс), «вид поставки» (собственного изготовления или покупное). Вторая таблица содержит поля «куда входит», «что входит», «количество». В пределах одной спецификации значение поля «куда входит» (то, что конструктор записывает в штампе) будет повторяться. Это значит, что, если мы хотим распечатать спецификацию, программа отфильтрует таблицу составов по нужному нам значению поля «куда входит», а значения поля «что входит» выведет в тело спецификации. Но поскольку в таблице составов у нас только идентификаторы изделий, то за информацией о наименованиях она сходит в таблицу изделий. Кроме того, эти записи будут сгруппированы в разделы по видам изделий, как того требует ЕСКД.

А теперь самое интересное: если мы будем фильтровать таблицу составов не по полю «куда входит», а по полю «что входит», мы получим некий обратный документ, ранее конструктору недоступный. Поскольку форма этого документа ЕСКД не предусмотрена, мы придумали её сами.

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

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

Но главное, что происходит при внедрении нашей системы – у инженеров меняется само восприятие конструкторского архива и номенклатуры изделий, выпускаемой предприятием. Теперь это не иерархически устроенная система папок, а некая сеть, в которой от любой точки (изделия) можно построить как классическое дерево вниз, так и дерево вверх. Или по-другому – «дерево содержания» и «дерево вхождения».

Иерархичность мышления поддерживала и общепринятая система обозначений. В этой системе обозначение изделия выглядит так: ФИРМА. АВТОМОБИЛЬ. 000. 000. 000 (ВАЗ. 21093. 000. 000. 000), где эти тройки нулей означают уровни вхождения (иерархию). Не хочу тратить время на выяснение реального количества и обозначения уровней, пусть в первой тройке нулей 100 будет кузов, 200 двигатель, 300 подвеска, 400 электрика. Тогда какая-то деталь наружной ручки двери будет иметь примерно такое обозначение ВАЗ. 21093. 100. 420. 153, где ВАЗ. 21093. 100. 420. 000 будет, естественно, дверь (например, передняя левая). А что, если нам захочется иметь такую сборочную единицу как ручка (простите за тавтологию) в сборе? Тогда нам придётся добавить в обозначение ещё один уровень. Например, ВАЗ. 21093. 100. 420. 225. 153, где «225» - та самая ручка в сборе. Почему я так подробно об этом рассказываю? Потому что, когда в 1993 году я делал доклад в НТЦ КАМАЗа, ко мне подошёл сотрудник завода, и сказал, что теперь он понял в чём у них проблема. Проблема была в том, что тележка с двумя ведущими осями (средней и задней), поставляемая на главный сборочный конвейер в сборе, не имела конструкторского обозначения по той самой причине, что на него не хватило уровня. Соответственно, на главном сборочном чертеже грузовика (и, соответственно, в главной спецификации) присутствовала не тележка в сборе, а все три оси. А теперь подумайте, как можно использовать в технологической и производственной системах объект, который отсутствует в конструкции изделия. Формально – никак. В реальности же автоматизаторы (ИТ-шники на новые деньги) для таких случаев придумывали какие-то свои идентификаторы, суррогаты конструкторских обозначений. Таким образом, параллельно существовали две иерархии, каждая со своими сборочными единицами: одна в конструкторской документации, вторая в реальном производстве, и обе – в информационной системе предприятия, у которой при таком подходе не было никаких шансов стать единой и непротиворечивой.

Получается, что выхода нет? Есть, и это не какая-то самодеятельность, а ГОСТ 2.201, являющийся частью ЕСКД и выпущенный ещё в 1980 году! Согласно этому ГОСТу все изделия (напомню, что это все, как бы сейчас сказали, информационные единицы: детали, сборочные единицы, комплексы и комплекты) полагается обозначать не по головному изделию, а по их форме (если это детали) или функциональному назначению (если это сборочные единицы, комплексы, комплекты). Поскольку в этой системе обозначения компонентов не носят следов обозначения головного изделия, в народе она получила название обезличенной.

Выглядит это обозначение так: XXXX.YYYYYY.ZZZ, где

XXXX – единый для всей документации код организации разработчика, который присваивается государством.

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

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

ZZZ – порядковый регистрационный номер. Наша система находила в базе последний номер изделия с этой же классификационной характеристикой и присваивала следующий.

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

Но система обозначений – это только одна проблема. Другая проблема заключается в том, что иногда конструктор или не понимает последовательность сборки изделия, или умышленно игнорирует эту последовательность ради удобства оформления своей части документации. В 2021 году я сделал ролик на эту тему и выложил его на YouTube. Поскольку сегодня далеко не все умеют преодолевать блокировки, а завтра мы вообще можем лишиться настоящего интернета, пересказываю содержание ролика здесь.

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

У обезличенной системы обозначений есть и дополнительный бонус, хотя на самом деле ради него одного уже бы стоило на неё переходить. Эта система обозначений является мощным средством для унификации изделий и создания рядов однотипных деталей. Поскольку классификационная характеристика довольно точно описывает геометрию детали, то даже без систем искусственного интеллекта и распознавания образов, только по одним этим 6-ти цифрам мы легко выудим из архива все крышки, зубчатые колёса, рычаги определённой конфигурации и другие детали определённой формы. Дальше их можно сравнивать, унифицировать, оптимизировать, уменьшать номенклатуру – делать что-то вроде своего Lego применительно к выпускаемой продукции и традициям предприятия. Здесь надо отметить титанический труд команды специалистов во главе с Самилем Львовичем Таллером по проработке этой идеи и разработке классификаторов. В 80-е годы имел с ним несколько телефонных разговоров, и очень жалею, что не познакомился ближе. Самиль Львович ушёл от нас в 2021, а ещё в 2019 Российский институт стандартизации отмечал его день рождения статьёй «Уникальная работоспособность». С 2004 по 2014 год я ездил в Москву по нескольку раз в месяц и вполне мог найти его, и у меня точно было о чём с ним поговорить и о чём у него спросить, но увы. Возможно, это самое большое профессиональное упущение в моей жизни, о котором я узнал только при подготовке этого материала.

Главное дело моей жизни. Часть 3.