Добрый день!
Заранее выражаю благодарность за внимание к теме и буду признательна за помощь.

Задача - создать систему для отслеживания дат предстоящего технического обслуживания спецтехники
на предприятии, управление и планирование состояния техники на определенную дату.
Имеем объекты: "машина", "двигатель машины", "календарь сроков обсуживания (ТО)", "пользователь".
К машине типа N подходит двигатель только типа K.
Для машины существует свой календарь сроков ТО, т.е на таком-то часу наработки необходимо проверить и/или заменить такие то детали.
Для двигателя существует тоже свой календарь проверок.
Ну и при наступлении даты следующего ТО, заблаговременно нужно оповестить пользователя.

Одно из главных требований к системе - создание гибких настроечных механизмов, для того, чтобы пользователи самостоятельно (без участия разработчиков):
- добавляли новые типы машин, двигателей,
- к каждому новому типу двигателя и машины создавали свой календарь.

Сложность в том, что границ при добавлении машин нет: может понадобиться добавить тип машины с двумя двигателями. Перечень всевозможного оборудования (атрибуты объектов) для каждого типа машины и двигателя уникальный. И календари уникальные (методы их обработки, алгоритмы расчета), форматы для атрибутов тоже уникальные (серийный номер у одной машины - 5 символов, а у другой - 16).

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

Я права в том, что при такой структуре данных, пользователи самостоятельно не смогут управляться с добавлением новых типов объектов ?
А если не права, кто нибудь может подсказать мне как это будет выглядеть на деле ?

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

Можете как-то подробнее описать, в чем именно вы видите проблемы?

>>Можете как-то подробнее описать, в чем именно вы видите проблемы? <<

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

Легче на примере, уже сейчас есть две машины:
У 1-ой машины - 38 деталей с ограниченным сроком службы. Какую то нужно проверить на 5 КМ наработки, какую то на 35 ЧАСАХ наработки, а третью на 5 км или 35 часах (что наступит ранее). Серийный номер машины состоит из 5 цифр + 1латиница.
У 2-ой машины совершенно другой комплект деталей, со своим графиками. Серийный номер состоит из 4 цифр. Данные для этих машин мы добавим в базу сразу.

Наступает завтра и пользователь (ролевая модель предусматривается) добавляет 3-ю машину:
График проверки для одной из деталей измеряется в количестве ЗАПУСКОВ. У пользователя будет возможность выбрать только
- часы наработки
- пройденный километраж
- часы наработки / километраж (что наступит ранее).
так как про количество ЗАПУСКОВ нам никто не сказал и мы не предусмотрели.

Плюс у этой машины еще появляется регистрационный номер состоящий из 15 цифр.

Как пользователь самостоятельно добавит маску для атрибута "рег. номер" ? Как укажет обязательность регист. номера для этого типа машины ?   Ведь, если не задаст, не удастся реализовать проверку на корректность введенного регистр. номера при добавлении единицы объекта.
А как добавит такой параметр для атрибута движка как "количество запусков"?

Про график обслуживания. Сложности могли бы возникнуть, если бы система должна была по-разному реагировать на разные виды событий графика обслуживания. Но реакций то всего две: 1. обслуживание по времени, причем точка отсчета введена в систему. Т.е. система знает точку отсчета и автоматически отслеживает время. 2. обслуживание на основании изменения информации, введенной пользователем. У вас же система не может автоматически контролировать пробег, запуски и прочее - она должна реагировать на изменение значения и сигнализировать о превышении этим значением заданного.
Т.о. все эти ваши запуски, пробеги и прочие виды, автоматически не контролируемые, ложатся в обычный какой-нибудь справочник.  Появился у вас третий тип автомобиля, в справочник событий просто добавляется "количество запусков". А уже при описании типа количество запусков ничем не отличается от пробега - указывается контрольное значение и отношение (меньше там или наоборот больше).  Системе все равно, что проверять поле под названием "пробег", в которую пользователи вводят числа или поле под названием "запуски", в которые те же самые пользователи вводят те же самые числа. А раз нет разницы, то список может и пользователь расширять.

А по поводу проверки корректности.  Пользователь сначала описывает тип автомобиля, куда как раз добавляет все агрегаты, графики ТО, маски и прочие данные. А уже потом создает экземпляры автомобиля этого типа. К тому моменту как создается конкретный автомобиль в системе уже сохранена информация, что у этого типа автомобиля сер.номер числовой 15-ти значный, а у этого  - 20 знаков смеси латиницы и цифр. Когда система показывает пользователю форму для ввода данных по автомобилю, в контроль данных этой формы уже заложены все необходимые проверки. Форма генерится каждый раз на основании сохраненных ранее данных.