Сообщение Re[2]: Выбор протокола, для работы с прибором от 27.03.2015 14:39
Изменено 27.03.2015 14:47 AlexGin
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexGin, Вы писали:
AG>>Доброго времени суток, уважаемые коллеги!
AG>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
K>АРМ это по русски читается или по английски? Что означает аббревиатура?
Автоматизированное Рабочее Место
K>Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
В данном случае запись — это единица информации, характеризующая набор отсчетов от датчиков прибора.
Это нейкий законченный набор отсчетов, над которым АРМ выполняет определенные математические расчеты.
K>Насколько быстро надо выгружать данные на АРМ?
K>АРМ это ваша железка и вы можете развернуть там любой софт?
Нет — АРМ это обычный комп (под Виндой).
K>Что за ОС используется на приборе и АРМ?
На АРМ — Windows 7 32/64 (SP1) и выше.
На приборе — как таковая ОС отсутствует.
Там совершенно специализированная система, на базе микроконтроллеров Atmel.
Собственно говоря, все что на приборе — это наша проприетарная разработка.
K>Нужна ли транзакционность передачи данных на АРМ?
Нет, это не финансовые данные, и не управление атомной станцией.
Если (в результате ошибки канала) одна/две записи пропадут — ничего страшного не будет.
K>В общем виде вы хотите просто передать все собранные данные на АРМ?
Да, именно так. Конечно, контроль за целостностью данных должен быть, но каких-либо жестких требований тут нет.
AG>>А какие ваши предложения, уважаемые коллеги?
K>От протобуф, буст сериалайз до ASN.1+BER и SQL.
Протобуф — это что за зверь?
Насчет буста — подумаю. Пока мне этот вариант не представляется более предпочтительным, нежели WinInet.
Так как для разработки применяем Visual Studio — то тут критерии выбора MFC или .NET.
MS SQL сервер у нас применяется — только на уровне БД АРМ. Для прибора связь с СУБД не актуальна.
AG>>P.S. Благодарю за любые предложения!
K>Да нечего предлагать. Вообще ничего не понятно.
Сорри, если описал ситуацию немного в нашей терминологии.
K>Здравствуйте, AlexGin, Вы писали:
AG>>Доброго времени суток, уважаемые коллеги!
AG>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
K>АРМ это по русски читается или по английски? Что означает аббревиатура?
Автоматизированное Рабочее Место
K>Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
В данном случае запись — это единица информации, характеризующая набор отсчетов от датчиков прибора.
Это нейкий законченный набор отсчетов, над которым АРМ выполняет определенные математические расчеты.
K>Насколько быстро надо выгружать данные на АРМ?
K>АРМ это ваша железка и вы можете развернуть там любой софт?
Нет — АРМ это обычный комп (под Виндой).
K>Что за ОС используется на приборе и АРМ?
На АРМ — Windows 7 32/64 (SP1) и выше.
На приборе — как таковая ОС отсутствует.
Там совершенно специализированная система, на базе микроконтроллеров Atmel.
Собственно говоря, все что на приборе — это наша проприетарная разработка.
K>Нужна ли транзакционность передачи данных на АРМ?
Нет, это не финансовые данные, и не управление атомной станцией.
Если (в результате ошибки канала) одна/две записи пропадут — ничего страшного не будет.
K>В общем виде вы хотите просто передать все собранные данные на АРМ?
Да, именно так. Конечно, контроль за целостностью данных должен быть, но каких-либо жестких требований тут нет.
AG>>А какие ваши предложения, уважаемые коллеги?
K>От протобуф, буст сериалайз до ASN.1+BER и SQL.
Протобуф — это что за зверь?
Насчет буста — подумаю. Пока мне этот вариант не представляется более предпочтительным, нежели WinInet.
Так как для разработки применяем Visual Studio — то тут критерии выбора MFC или .NET.
MS SQL сервер у нас применяется — только на уровне БД АРМ. Для прибора связь с СУБД не актуальна.
AG>>P.S. Благодарю за любые предложения!
K>Да нечего предлагать. Вообще ничего не понятно.
Сорри, если описал ситуацию немного в нашей терминологии.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexGin, Вы писали:
AG>>Доброго времени суток, уважаемые коллеги!
AG>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
K>АРМ это по русски читается или по английски? Что означает аббревиатура?
Автоматизированное Рабочее Место
K>Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
В данном случае запись — это единица информации, характеризующая набор отсчетов от датчиков прибора.
Это нейкий законченный набор отсчетов, над которым АРМ выполняет определенные математические расчеты.
K>Насколько быстро надо выгружать данные на АРМ?
K>АРМ это ваша железка и вы можете развернуть там любой софт?
Нет — АРМ это обычный комп (под Виндой).
K>Что за ОС используется на приборе и АРМ?
На АРМ — Windows 7 32/64 (SP1) и выше.
На приборе — как таковая ОС отсутствует.
Там совершенно специализированная система, на базе микроконтроллеров Atmel.
Собственно говоря, все что на приборе — это наша проприетарная разработка.
K>Нужна ли транзакционность передачи данных на АРМ?
Нет, это не финансовые данные, и не управление атомной станцией.
Если (в результате ошибки канала) одна/две записи пропадут — ничего страшного не будет.
Простой подсчет КС (контрольной суммы) здесь вполне обеспечит проверку валидности данных.
K>В общем виде вы хотите просто передать все собранные данные на АРМ?
Да, именно так. Конечно, контроль за целостностью данных должен быть, но каких-либо жестких требований тут нет.
AG>>А какие ваши предложения, уважаемые коллеги?
K>От протобуф, буст сериалайз до ASN.1+BER и SQL.
Протобуф — это что за зверь?
Насчет буста — подумаю. Пока мне этот вариант не представляется более предпочтительным, нежели WinInet.
Так как для разработки применяем Visual Studio — то тут критерии выбора MFC или .NET.
MS SQL сервер у нас применяется — только на уровне БД АРМ. Для прибора связь с СУБД не актуальна.
AG>>P.S. Благодарю за любые предложения!
K>Да нечего предлагать. Вообще ничего не понятно.
Сорри, если описал ситуацию немного в нашей терминологии.
K>Здравствуйте, AlexGin, Вы писали:
AG>>Доброго времени суток, уважаемые коллеги!
AG>>Мы разрабатываем прибор, который собирает информацию (от датчиков) и передаёт на АРМ.
K>АРМ это по русски читается или по английски? Что означает аббревиатура?
Автоматизированное Рабочее Место
K>Записи имеют фиксированные поля? В каком формате записи текст, бинарный? Это записи это термин паскаля?
В данном случае запись — это единица информации, характеризующая набор отсчетов от датчиков прибора.
Это нейкий законченный набор отсчетов, над которым АРМ выполняет определенные математические расчеты.
K>Насколько быстро надо выгружать данные на АРМ?
K>АРМ это ваша железка и вы можете развернуть там любой софт?
Нет — АРМ это обычный комп (под Виндой).
K>Что за ОС используется на приборе и АРМ?
На АРМ — Windows 7 32/64 (SP1) и выше.
На приборе — как таковая ОС отсутствует.
Там совершенно специализированная система, на базе микроконтроллеров Atmel.
Собственно говоря, все что на приборе — это наша проприетарная разработка.
K>Нужна ли транзакционность передачи данных на АРМ?
Нет, это не финансовые данные, и не управление атомной станцией.
Если (в результате ошибки канала) одна/две записи пропадут — ничего страшного не будет.
Простой подсчет КС (контрольной суммы) здесь вполне обеспечит проверку валидности данных.
K>В общем виде вы хотите просто передать все собранные данные на АРМ?
Да, именно так. Конечно, контроль за целостностью данных должен быть, но каких-либо жестких требований тут нет.
AG>>А какие ваши предложения, уважаемые коллеги?
K>От протобуф, буст сериалайз до ASN.1+BER и SQL.
Протобуф — это что за зверь?
Насчет буста — подумаю. Пока мне этот вариант не представляется более предпочтительным, нежели WinInet.
Так как для разработки применяем Visual Studio — то тут критерии выбора MFC или .NET.
MS SQL сервер у нас применяется — только на уровне БД АРМ. Для прибора связь с СУБД не актуальна.
AG>>P.S. Благодарю за любые предложения!
K>Да нечего предлагать. Вообще ничего не понятно.
Сорри, если описал ситуацию немного в нашей терминологии.