Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
31 марта

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Средства и методы разработки

309884 Топик полностью

Evgeny_CD^{Архитектор} (24.02.2012 14:03, просмотров: 759) ответил =AlexD= на Т.е. лог вы уже ведёте, исходный массив данных уже есть?

Не понял вопроса.

Ответить

- 4м событий вы получаете, складываете в файл, накапливаете - всё это уже есть и работает? - =AlexD=(24.02.2012 14:07)
  - Если в файл складыается 1к событий в сек (система медленная, сейчас говнокодерские ошибки выловили, можно мониторить только важное), и вместо FPGA стоит "микроконтроллер для логгинга" - что изменится для Вас? Что именно я делаю в рамках своих Evgeny_CD(29 знак., 24.02.2012 14:10)
    - Я просто пытаюсь понять, что полезного даёт вам гиг подобных логов? Есть польза, или процесс не выходит за рамки ручного изучения логов, когда система ведёт себя не по спецификации? - =AlexD=(24.02.2012 14:26)
      - Простой пример. Едет машина "по дорогам и по взгорьям" с GPRS девайсом. Связь то есть, то нет. Юзер звонит голосом, ему звонят. Есть 3 замечательных сущности: Evgeny_CD(368 знак., 24.02.2012 14:33)
        
        SQL это слишком круто. Практически в похожей ситуации можно записывать тупо текстовые файлы. Или "полутекстовые", когда вместо текстов записываются ссылки на адрес строки в ПЗУ (потом этот поток легко декодируется если есть бинарник записавшей fk0(220 знак., 24.02.2012 14:52)
        
        Потому, что SQL стандартен и удобен, при базе в памяти очень быстр. Для целей разработки экономия ресурсов не так важна. Для экономии памяти помогает предварительный парсинг - неважные записи игнорируем. Но это ухудшает полноту картины. - Evgeny_CD(24.02.2012 14:57)
        
        Тем не менее вы ушли от ответа ;-). Понятно, что в 4Г логе нужно найти пропадание связи в некотором промежутке времени и прошерстить внутренние переходы состояний программы. Но сможете ли вы найти баг, если юзверь не жаловался? :-) - =AlexD=(24.02.2012 14:41)
        
        В общем, иногда можно. Если поведение системы при нормальной работе должно соответствовать некому шаблону (последовательность действий, соответствующих им диагностических сообщений), при ненормальной работе шаблон не подходит. Вопрос как fk0(41 знак., 24.02.2012 14:54)
        
        Мои экземпляры объектов класса "юзер" выдавали в stdout только "Вы мудаки! Ничего не работает!" :) В общем, если никаой реакции нет - можно и не рисечить. Но иногда, в важных проектах, ма привентивно пускали тестовую машину, и потом анализировали Evgeny_CD(52 знак., 24.02.2012 14:54)
        
        Ну в общем понятно, мегалоггинг с некоторыми инструментами выковыривания данных. Я то думал, что вы нашли способ более-менее строгого определения корректности работы системы, и точите инструментарий под полную автоматизацию. - =AlexD=(24.02.2012 15:06)
        
        Я бы сказал так, это правильная цель, но я понимаю как ее достичь только для узких задач. Т.е. вот сейчас делается простое устройство с высокой надежностью, там будет отдельный программно-аппаратный модуль контроля правильности работы. Но там Evgeny_CD(82 знак., 24.02.2012 15:33)
        
        Нет, о таком я пока аккуратно так мечтаю внутри себя :) - Evgeny_CD(24.02.2012 15:09)