real time ratio changes in os что это
Real time ratio changes in os что это
Настройки Bios под 4,5 ГГц:
Любопытный момент с напряжением при множители 43-46 X, 1,375 не загружается система, при 1,385 происходят зависания системы, в среднем за 2-3 минуты, при 1,390-1,395 зависание раз в час, при 1,4 только во время стресс-теста OCCT, зависает быстро за пару минут. Система стабильна только она 42, даже если выставить напряжение 1,3!
Такое ощущение, что процессор на отказ не хочет работать на 4,3 и выше, но в сети видно, что он без проблем должен брать 4,5.
Подскажите пожалуйста, может надо отрубить какие-то настройки? Или выставить большее напряжение в других параметрах? По температуре у меня запас большой, кулер на 600 оборотах, вместо 1400, обидно терять производительность(((
Вот что я сделал, что бы заработало на 4,6 ГГц:
Включил Internal CPU PLL Overvoltage (как я понял он позволяет разгонять выше 4,5 ГГц)
Отключил Real-Time Ratio Changes in OS
Отключил Intel ® Turbo Boost Tech
Отключит энергосберегающие настройки (С1E), C3/C6, EIST
X.M.P. отключать не стал, потому что был уверен, что проблема не в памяти
Multi-Steps Load-Line поставил Level 6 (при любом другом значении выскакивает синий экран, не думал, что это так важно)
Load-Line Calibration включил, все рекомендуют его ставить Enabled при разгоне
CPU Vcore 1.320V
QPI/Vtt Voltage 1.080V
System Agent Voltage 0.955V
PCH Core 1.080V
CPU PLL 1.900V
DRAM Voltage 1.640
При таких настройках, система смогла пройти два часа теста на OCCT, при 4,6 ГГц. До этого выскакивал синий экран при 4,3 ГГц за 1-2 минуты теста при 1.4V. Так что какой-то параметр явно, очень сильно мешал разгону.
Спасибо за ответы, вот фото стабильного разгона:
RTOS или не RTOS вот в чем вопрос
Термин ОС РВ (RTOS) относится к области маркетинга!
Я думал начать по-научному, с введения терминов, но решил, что данный провокационный тезис будет как нельзя кстати. Итак, почему же я утверждаю, что термин ОСРВ (операционные системы реального времени) относится к маркетингу, точнее, является маркетинговым (рекламным) слоганом? Все просто. Когда производится какой-то товар, его нужно продавать. Но если вы попробуете продать просто операционную систему, возникнут трудности. Тут приходит на помощь позиционирование на рынке. Например, можно сказать “мы более быстрые, чем они”.
Но за это можно попасть под суд! А там потребуется предоставить доказательства. Но как доказать, что ты более быстрый во всех случаях? Это же не соревнование по бегу. Но конечно, такая не совсем корректная конкурентная борьба слегка выбивается из нормального позиционирования на рынке.
Нормальное позиционирование подразумевает формирование портрета потребителя выявление свойств продукта, которые у него более востребованы, и фокусировка на этих свойствах. Ну или формируешь у пользователя эти потребности. Например, наш процессор имеет такую-то частоту, смартфон имеет аж N-ядерный процессор, и так далее.
Поскольку классики жанра уже сформулировали, что операционные системы нужны не только для пользовательских систем, но и для управления различными технологическими процессами в автоматическом режиме и даже ввели понятие операционная система реального времени, то тут, сами понимаете, грех не воспользоваться. Вводя понятие систем реального времени классики говорили о некоем критическом пороге времени. То есть в отличает от обычных систем, где если пользователь чего-то ждет, то может и подождать, система жесткого реального времени, например управляющая турбиной, подождать не может, а то можно докрутиться до чего-нибудь нехорошего.
Таким образом можно сказать пользователю, что ему в отличие от обычных операционных систем предоставят систему, которая гарантирует время реакции системы. Естественно чем оно меньше, тем большим числом различных технологических процессов система может управлять. И появляется множество таблиц, где в качестве ключевого параметра приводятся различные временные параметры RTOS.
Как они получены? Этот процесс честно описан! Вот берем такую-то модельную задачу, такую-то аппаратную платформу и так-то подаем воздействие. Ну маркетинг, естественно, может упростить и просто выдать, время реакции 1 мкc. Но мы это не принимаем в расчет, считаем, что все честно описано.
Но простите, а если будет другая задача? 10 задач, 100 задач? А если пьяный программист залочит прерывания? А если в системе программист не правильно расставил приоритеты задач?
Был случай когда Embox проходил испытания на реал-таймовость. Мы сидели и думали как доказать, что это операционная система реального времени. Есть лаборатория, есть заказчик, который хочет чтобы это было так. Выясняем, что для заказчика реал-таймовость означает время реакции системы 1 мкс. Спрашиваю, а будет ли являться доказательством следующий эксперимент:
Данный раздел написан ни в коем случае не для того, чтобы принизить какие-то ОС или каких-то разработчиков. А исключительно, чтобы показать всю неполноту картины. Я не утверждал, что характеристики каких-то ОС не позволяют их относить к ОСРВ, а только что данный термин используется маркетологами. Я видел и другие испытания, когда заказывали выбор операционной системы независимой лаборатории исходя из требований задачи. Там был сложный набор модельных задач, рассматривались и сетевое взаимодействие, и как меняются параметры, если система загружена, и поведения в различных нештатных ситуациях.
Определение термина “Операционная система реального времени”
Система может считаться системой жесткого реального времени, если в ней нет мест, где при залоченных прерываниях, есть циклы с неизвестным числом итераций.
«Another type of operating system is the real-time system. These systems are characterized by having time as a key parameter. For example, in industrial process control systems, real-time computers have to collect data about the production process and use it to control machines in the factory. Often there are hard deadlines that must be met. For example, if a car is moving down an assembly line, certain actions must take place at certain instants of time. If a welding robot welds too early or too late, the car will be ruined. If the action absolutely must occur at a certain moment (or within a certain range), we have a hard real-time system. Many of these are found in industrial process control, avionics, military, and similar application areas. These systems must provide absolute guarantees that a certain action will occur by a certain time.
Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.
Since meeting strict deadlines is crucial in real-time systems, sometimes the operating system is simply a library linked in with the application programs, with everything tightly coupled and no protection between parts of the system. An example of this type of real-time system is e-Cos.
The categories of handhelds, embedded systems, and real-time systems overlap considerably. Nearly all of them have at least some soft real-time aspects. The embedded and real-time systems run only software put in by the system designers; users cannot add their own software, which makes protection easier. The handhelds and embedded systems are intended for consumers, whereas real-time systems are more for industrial usage. Nevertheless, they have a certain amount in common.”
Но и из этого описания следует только, что системы могут применяться в системах где отсутствие реакции в заданный срок может привести к катастрофическим последствиям. Ну еще в целях достижения ключевого параметра (не превышения времени реакции) ОС могут представлять из себя библиотеку, пример eCos.
Как же добиться характеристик реального времени
Строгого определения у меня дать не получилось (если кто-то готов дать, пишите в комментариях). Но во всех вышеперечисленных определениях видно пару свойств (это время и предсказуемость). Если перевести время в опцию предсказуемости (вес дуги при переходе из одного состояния в другое), то остается только предсказуемость!
Давайте подумаем, как этого добиться.
Очевидным будет убрать все лишнее из критической системы. Универсальную систему вряд ли получится сделать стабильной. Даже товарищ Таненбаум об этом говорил, я имею в виду, когда он говорил о eCos.
Еще одним подходом, увеличивающим предсказуемость системы, опять же, предложенный Таненбаумом, является использование специальных (простых) алгоритмов для планирования ресурсов, в первую очередь процессорного времени, то есть специальных планировщиков задач. Он предложил несколько подходов к планированию, но я бы хотел в первую очередь остановиться на статической таблице планирования (Static table-driven).
Разработчик должен гарантировать, что все задачи успевают выполниться в свой квант времени. Для этого предлагается статически проанализировать критическую задачу и определить ее пороговые значения. Именно этот подход заложен в стандарт ARINC-653. Стандарт для бортовых систем, и сами понимаете, если у самолёта что-то вдруг не успеет отработать, то может случиться катастрофа.
Следующим подходом является статическое расписание, но на основе приоритетов. То есть разработчик должен опять же проанализировать все ситуации и, присвоив всем задачам в системе приоритеты, обеспечить выполнение критически важных задач в заданное время.
Продолжать не хочется, ведь есть оригинал! Написан он, конечно, лучше, чем это могу сделать я, ну и к тому же, опять могут обвинить в искажении фактов. Привел я именно эти подходы для того, чтобы показать, что в любом случае на разработчика конечной системы ложится ответственность за обеспечение характеристик системы. А операционная система должна только предоставить соответствующие возможности.
Продолжая рассуждения о методах повышения предсказуемости, хочу привести еще один комментарий
“На малинке можно добиться реального времени, но не с RTOS, а с маленькой стэйт машиной влезающей в его кэш.”
Здесь хочу обратить внимание на следующие моменты:
Что есть влияние аппаратной части тоже скорее всего не вызывает сомнений. В частности, когда говорилось об отсутствии циклов с произвольным количеством итераций в состоянии залоченных прерываний, звучало, что на каком-то cortex-m в описываемой RTOS вообще нет отключения прерываний. Это немного лукавство, ведь там контроллер прерываний отключает прерывания с равным или более низким приоритетом, самостоятельно, но факт влияния налицо. Ну и конечно, наличие cache, трансляции адресов (точнее промахов по страницам), вносит свою лепту неопределенности. Особенно, я хотел обратить внимание еще на тот факт, что вообще-то на сто процентов гарантировать правильную работоспособность аппаратуры никто не может. Ну вот отвалился у вас проводок, как наличие ОСРВ позволит избежать катастрофического исхода событий?
Представление программы как машины состояний, хотел бы предложить рассмотреть с неочевидной стороны. А именно, что программа для повышения предсказуемости может анализироваться. А поскольку речь идет о всех состояниях, то она должна анализироваться, причем статически, на все возможные ситуации. Ну а поскольку статическому анализу гораздо лучше поддаются функциональные языки программирования, то возможно разрабатывать программу следует и на некоем специальном языке, или добавлять использование специальных языков программирования. Первый подход используется, например, в верифицированным ядре seL4. Примером второго подхода, является все тот же стандарт ARINC-653, с его обязательным формированием требований на языке XML.
Существуют и другие методы, повышающие предсказуемость или, если хотите, факторы влияющие на предсказуемость системы. Я делал доклад по данной теме на одной из конференций OSDay. В частности, кроме уже перечисленных, я выделил еще архитектурный подход. Ведь общеизвестно, что, например, микроядерная архитектура может увеличивать предсказуемость системы. Но еще в том же докладе был выделен несколько неочевидный, организационный подход. Здесь речь как раз о том моменте, где я не согласился, что отсутствие RTOS ведет к увеличению предсказуемости. Если задуматься, то вообще понятие операционной системы позволило существенно сократить количество ошибок за счет переиспользования кода. То есть, если у вас не код, который реально влезает в один switch/case, то лучше использовать готовые модули. Ведь параметр „количество ошибок на 1000 строк кода“ никто не отменял, и каким бы отлаженным ни был ваш новый код, там есть ошибки.
ОСРВ вообще существуют?
Остановившись на в предыдущем разделе, на утверждении, что в любом коде есть ошибки, хочу высказать еще один провокационный тезис. ОСРВ вообще существуют?
Давайте разберемся. Дискутируя со знакомым по поводу систем реального времени, договорились до того, что операционная система реального времени (мы говорим о системах жесткого реального времени), вряд ли может существовать. Он предложил представить всю систему как машину состояний или граф с описанием максимального времени перехода из одного состояния в другое. При этом система может считаться стабильной, если доказано что при всех входных и внутренних состояниях, существует дуга, ведущая в заданное состояние с ограничением по времени. Ну а сами понимаете, такое возможно только для очень маленькой системы, как раз той самой машины состояний, упомянутой в комментарии, но в современном мире подобная система мало кому нужна.
Но мы же не сомневаемся, что системы реального времени существуют. Ну и конечно, ОСРВ тоже. Если бы это было не так, то первый залетевший дятел разрушил бы цивилизацию, то не было бы авионики, космонавтики, робототехники, АСУ-ТП да и многого другого.
Как выходят из ситуации. Очень просто, хотя в общем задача, скорее всего не решаемая, но для конкретной задачи, можно ввести ограничения, которые делают ее разрешимой, с какой то осмысленной вероятностью ошибки.
Например, вводятся стандарты: realtime POSIX, ARINC-653, ITRON. Данные стандарты, по сути дела, выделяют класс задач, которые могут быть решены, если придерживаться данного стандарта. Или проводятся исследования независимыми лабораториями, которые изучают подходят ли свойства конкретной ОС, для решения целевой задачи.
Так Embox RTOS или не RTOS?
На мой взгляд, ответить на подобный вопрос, как для Embox так и для любой другой ОС, можно только вопросом: “Что Вы имеете в виду?”. Точнее: “А что Вы подразумеваете под понятием реального времени?”. То есть, если интересует время обработки прерывания, и можно ли вызвать обработчик прерывания напрямую, — это одно, если нужно повысить надежность работы, пусть медленно, но зато точно гораздо меньше вероятность сбоя, — это другое, соответствие какому либо стандарту — это третье, возможность верификации — это четвертое. Не случайно великий классик Андрю Таненбаум, хоть и предложил методы повышения предсказуемости, и использовал само понятие система реального времени, но воздержался от каких-то строгих определений.
Операционные системы реального времени для начинающих
Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.
Что такое ОСРВ?
Зачем она нам нужна?
На то есть довольно много причин.
Во-первых ОСРВ поддерживает многозадачность, приоритеты процессов семафоры и многое другое.
Во-вторых она очень легкая и почти не требует ресурсов.
В-третьих все вышесказанное мы можем получить практически на любом железе (например, FreeRTOS запускается даже на 8-битных AtMega).
Ну и в-четвертых: просто поиграться и получить удовольствие.
Обзор 3 известных ОСРВ.
Внимание: дальше идет мое личное мнение.
FreeRTOS
Одна из самых популярных ОСРВ на сегодняшний день. Портирована на огромное количество железа. Оффициальный сайт.
Плюсы
Минусы
1)Довольно-таки сложный процесс портирования на новое железо.
Вывод: Это действительно профессиональная ОСРВ с хорошей документацией. Будет хороша для новичка, если на его железо уже есть порт.
KeilRTX
До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт.
Плюсы
1)Бесплатная
2)Легко портируется на новое железо( в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.
Минусы
1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.
Мощная коммерческая ОСРВ. Сайт.
Плюсы
Минусы
1)Коммерческая.
2) Сложна в использовании.
Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.
Другие интересные ОСРВ
RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.
Особенности разработки с использованием ОСРВ
Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы( или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет — то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер — когда процессу нужен ресурс — он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму( и так — до бесконечности).
Дополнительные библиотеки ОСРВ.
Часто ОСРВ предлагают различные библиотеки для работы, например, с графикой, интернетом и т.д. Они действительно удобны и не стоит брезгать их использовать. Однако, помните, что без ОСРВ, для которой они написаны, они работать не будут.
Вот примеры:
Для RTX графика интернет Файловая система
Во второй( и, наверное, последней ) части мы поговорим о мьютексах, буферах сообщений и попрактикуемся в их использовании.
Very simple real time operating system: что это и зачем нужно?
В своей предыдущей статье я вскользь упомянул, что использую в проекте операционную систему реального времени собственной разработки vsrtos, которая по внешнему API похожа на FreeRTOS. Так зачем же нужно было ее разрабатывать, и когда стоит сделать выбор в ее пользу вместо FreeRTOS?
В этой статье будут разобраны плюсы и минусы использования vsrtos и FreeRTOS для определенного ряда задач, ради которых vsrtos и была разработана.
Предпосылки к созданию
В один из своих домашних проектов (о нем планирую рассказать в одной из следующих статей), после тщательной оценки требований к аппаратным ресурсам, я заложил микроконтроллер stm32l010k8 (Cortex-M0, 64 KB Flash, 8 KB RAM). По моим расчетам, я мог не задумываясь решить задачу, даже используя десяток потоков FreeRTOS. Собственно, так оно и получилось. Прототип работал хорошо и стабильно, а у меня оставалось 3 килобайта неиспользованной RAM. Далее мне захотелось расширить функционал устройства. Однако в проекте имеется LCD экран на базе контроллера ST7920 с разрешением 128 на 64 пикселя, подключенный по SPI. Для прошлой задачи скорость его обновления была достаточной, но для решения этой уже требовались доработки.
Несколько слов о работе с экранами на основе контроллера ST7920 по SPI
Изображение с чужой статьи
Изначально в проекте был выделен буфер под изображение на экране, размером один килобайт (128 * 64 / 8). И буфер под двойную строку (256 * 3) в формате пакетов, пригодных для отправки в экран по DMA. Данные из буфера изображения экрана построчно копировались в буфер для отправки, преобразовывалась на ходу в формат пакетов SPI для ST7920.
В итоге, для обновления экрана требовалось:
Выставить координаты X/Y для каждой двойной строки
Преобразовать строку изображения к формату для отправки
Установка X/Y происходила отправкой независимых пакетов по 3 байта, отправка двойной строки цельным куском. И команды и данные передавались по DMA.
При таком подходе было заметно, как перерисовывается изображение. К тому же, максимальная частота SPI у данного экрана 500 кГц, что еще больше осложняло дело. Поразмыслив над тем, что у меня осталось от решения задачи на прошлом этапе, я решил изменить принцип работы с экраном и его изображением следующим образом:
Хранить изображение не в удобном для рисования формате, а в пригодном для отправки по SPI. Из-за этого объем RAM, требуемый для хранения изображения вырос в 3 раза (на 1 байт полезных данных 3 для отправки).
Держать команды позиционирования курсора на экране вместе с изображением. Это также увеличило потребления RAM.
Отправлять данные не кусками, а цельным блоком. И команды и данные вперемешку.
Значительно выросло потребление RAM
Пришлось переписать библиотеку рисования примитивов, чтобы она рисовала сразу в пригодном для отправки формате и игнорировала заголовочные команды в начале каждой сдвоенной строки.
Но, так или иначе, цель была достигнута. Отрисовка начала происходить очень быстро и начала удовлетворять требуемой для расширенной задачи скорости.
Однако, возник нюанс. На решение новой задачи уже не хватало RAM… По моим прикидкам, около 700 байт. Потоки FreeRTOS падали один за другим или происходили зависания в разных частях кода. И, больше всего выводило из себя то, что FreeRTOS не давала толком понять, где именно не хватало памяти. Я начал копаться в ее недрах и понял, что есть множество причин, которые могут не позволить программной защите памяти указать мне, что у задачи закончилось место под стек. В этом случае у меня было два варианта:
Вернуть все как было и сделать конвертацию в формат SPI для ST7920 “на лету”, производя отправку в прерываниях от SPI.
Как-то снизить потребление RAM сервисными функциями.
Переделывать все на работу по прерываниям мне не хотелось. DMA не для того изобретали, чтобы я 20% процессора тратил на конечный автомат в прерывании. А вот идея снизить потребление RAM показалась здравой.
После оценки потребления по map файлу (во FreeRTOS использовалась только статическое выделение памяти, в heap в проекте ни в каком виде не использовался. Даже sbrk), я пришел к выводу, что объекты FreeRTOS занимают примерно 25% проекта (сюда входят как используемые семафоры/мьютексы/очереди, так и внутренние данные самой FreeRTOS, необходимой ей для работы). Остальное же было занято стеками задач и новоиспеченным буфером почти в 3.2 килобайта. Выделенные стеки задач мне также казались сильно большими, но и их не хватало (об этом ниже).
Сравнение операционных систем
Недостатки FreeRTOS выходят из ее достоинств:
Портирована под множество архитектур
Лишние уровни абстракции, которые потребляют стек при использовании под конкретную архитектуру
Структуры базовых компонентов универсальны (очереди, мьютексы, семафоры)
Большее потребление RAM
Большое количество возможностей, которые покрывают широкий спектр задач
Много неиспользуемого кода, который усложняет восприятие при чтении
Можно создавать задачи как статически, так и динамически
Код сложнее читать из-за двух разных видов инициализации (хотя внутри все сводится к одному механизму). К тому же, связывание между задачами происходит в момент регистрации задачи в процессе выполнения программы. Это ведет к более сложному анализу происходящего при падениях в HardFault
Все компоненты инициализируются по ходу выполнения программы
Невозможность без выполнения оценить всю связанность в проекте
Поскольку в 95% случаев мне приходится работать с микроконтроллерами на основе Cortex-M (которые во всей линейке обратно совместимы, за исключением конкретных дополнительных возможностей в каждый более новой линейке), то было принято решение написать ОС, которая была бы максимально оптимизированной и простой для чтения только под одной архитектурой. Однако, реализуя эти принципы, она автоматически лишается описанных выше достоинств FreeRTOS.
Возможности, преимущества, недостатки
Возможности и преимущества:
Реализован API, покрывающий основные потребности в RTOS, совместимый с FreeRTOS:
Вход в критическую секцию/выход из критической секции (только в потоке).
Принудительное переключение задачи (можно вызвать как из потока, так и из прерывания)
Получение времени (из потока или из прерывания), ожидание до метки времени/ожидание в течении заданного периода (только из потока)
Блокировка/разблокировка мьютекса (только из потока)
Получение семафора (только из потока), выдача семафора (из потока и из прерывания)
Получение данных из очереди (только из потока), отправка данных в очередь (из потока и из прерывания)
Инициализация всех потоков происходит в одном месте и описывается пользователем в виде массива константных структур. Это гарантирует, что никакое повреждение стека не сломает конфигурацию задач.
Проверка переполнения стека происходит на этапе каждого переключения контекста относительно данных из неизменной конфигурации задачи. Таким образом, в 100% случаев переполнение будет определено (если только не посыпалась flash, но тогда у меня вообще плохие новости…).
Недостатки
Менее гибкая, чем FreeRTOS.
Приходится вручную задавать все связи между объектами.
Работает на момент написания статьи только с Cortex-M0 (в дальнейшем планирую увеличить список до всей линейки Cortex-M. Там минимальные отличия).
Примеры использования
В качестве примера использования может служить программа из предыдущей статьи. В дальнейшем я планирую дополнять документацию перечнем проектов, в которых данная операционная система была использована.
Выводы: когда стоит сделать выбор в пользу vsrtos вместо FreeRTOS?
Повлиять на решение в пользу vsrtos могут следующие причины:
У вашего микроконтроллера мало памяти, а ОС все же требуется
Вам не очень нравится падать в hardfault по непонятным причинам, с последующим выяснением того, что ваш поток перезаписал часть системных данных ОС, а потом вы упали совершенно в другом месте при попытке воспользоваться этими данными
Вам требуется надежное связывание объектов на этапе компиляции для повышения надежности