Ага

Проверка решений тут происходит следующим путем: первое это синтаксический анализ, есть ли ошибки в коде, потом этот код передается на runtime, который представляет собой цикл плк: работа с входами, цикл программы, работа с выходами. Тестовые кейсы знают что на входе, что должно быть на выходе, а также состояние входов и выходов каждый период времени. В системе сейчас это 100 ms. Если условно на 300 ms выход не соответствует эталонному, то будет ошибка

Логично, по шагам ловит почти всё. Меня всегда кусало накопленное состояние: таймеры, защёлки, фронты. Одиночный цикл зелёный, а на N-м уже расходится. Гоняете это длинной последовательностью?

Тут мне стоит уточнить, что означает длинная последовательность?

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

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

Согласен, для чистой комбинаторики первый полный цикл всё закрывает. А ломается там, где состояние переносится между циклами или приходит вход не из кейсов. По сути упирается в тестовые данные, ты прав.