Здравствуйте, gulfsrteam, Вы писали:
G>Насколько я понял, проблема была в том, что выбивались ячейки памяти, ответственные за счетчики установки сессии и подсчета количества логинов между прикладным ПО и токеном по интерфейсу PKCS11/APDU (C_OpenSession, C_Login).
При таких симптомах это говорит о том, что достигался критический уровень по количеству записей в EEPROM. Обычно это 10000 или 100000 раз на страницу памяти, после чего может возникать разрушение данных.
Чтобы улучшить эти показатели, используют несколько приемов. Например, алгоритм под названием wear leveling. Он работает так: частые записи одних и тех же данных не попадают только в одну ячейку EEPROM, а равномерно распределяются по всем доступным ячейкам. Соответственно, равномерно распределяется и износ ячеек памяти, что статистически увеличивает кол-во доступных операций записи без повреждения данных. Т.е. если есть EEPROM размером в 32768 байт из которых часто записывается только 16 байт, wear leveling даст 32768 / 16 = 2048-кратное увеличение количества доступных записей, что из 3 месяцев безотказной работы сделает целых 512 лет. На практике, микросхемы EEPROM поддерживают только постраничную запись, т. е. если мы хотим записать только 16 байт, то придётся записывать целую страницу в которой эти 16 байт находятся. Размер страницы зависит от конкретного устройства, в микроконтроллерах это, например, 256 байт. Страничная запись несколько снижает потенциал wear leveling алгоритма, но тем не менее даже при 256 байтах размера страницы он обеспечит кратность 32768 / 256 = 128, что из 3 месяцев безотказной работы сделает 32 года.
Еще один приём: использовать кеш в ОЗУ и не писать в EEPROM до тех пор, пока не наступит событие потери энергии. Приведу пример: в устройстве есть импульсный источник питания, на входе которого уже стоит жирный конденсатор, который накапливает энергию достаточную для нескольких секунд работы устройства даже после потери основного питания. Дополнительно на входе основного питания 220 В ставят оптопару, позволяющую микропроцессору отслеживать присутствие этого питания. Когда этот сигнал пропадает на дольше чем, например, 50 мс, то процессор уже знает, что кешированные данные нужно немедленно сохранить в EEPROM и начинает соответствующую операцию записи. Энергии запасенной в конденсаторе хватает чтобы запись завершилась до полного обестачивания системы. Таким образом и данные сохраняется и EEPROM используется только тогда, когда это действительно нужно, т.е. при включении и выключении питания. А так как включение и выключение устройства это относительно редкие события, то ресурса EEPROM хватает на очень долго, особенно если это совместить с wear leveling алгоритмом.
Но чтобы это всё уметь делать, нужен доступ к достаточно низкому уровню ОС и железа, что зачастую проблематично когда используются готовые модули — они попросту могут этого не уметь.
Но учитывая обороты предприятия, можно было бы вполне перейти на полный цикл разработки, т. о. полностью решив эту проблему.
