Актуальная спецификация Railcom
Добавлено: Пн янв 15, 2018 11:12 am
Опишу здесь свои изыскания о спецификациях RailCom и стандартах RCN, может быть кому то пригодиться.
Первая спецификация BiDi была разработана Lenz в начале 2000-ых. Проблема была в том, что Lenz не хотел её бесплатно делиться, но при этом хотел, чтобы все использовали именно её. При этом у Zimo был свой взгляд на системы обратной связи в декодерах, они разработали свой протокол BiDi в 2000 году.
Lenz оформил патент на свой протокол причём как в Германии, так и в США и передал спецификация в NMRA что решало вопрос об их использовании сторонним производителями, где она получила статус регламентного предписания RP-9.3.1 и RP-9.3.2 и была опубликована в 2003 году, началась «патентная война Ленца». Позже спецификации были откорректированы RP-9.3.1 в 2007 году, RP-9.3.2 в виде драфт версии вышла в 2005 и просуществовала до 2012.
Но сообщество производителей ЖД модельной электроники не одобрили поведение господина Ленца, единственной системой с поддержкой RailCom была продукция его главного конкурента - Zimo, станция MX31ZL ставшая первым коммерческим продуктов с RailCom в мире.
В начале 2010-ых ESU заинтересовалось темой RailCom, для его реализации в своих новых разработках, в результате этого сотрудничества у Lenz родилась новая кардинально пересмотренная спецификация RailCom, получившая номер 1.2. На основе этой пересмотренной спецификации в NMRA разработали уже стандарт S-9.3.2 от 2012 года, фактически опубликованный в 2013. Указанный стандарт заменял собой RP-9.3.1 и RP-9.3.2, так как описывал как физическую часть, так и протокол в одном документе.
Но производители не стремились к реализации Railcom в своих продуктах, «Война Ленца» продолжалась. Ситуация изменилась благодаря образованному в 2009 году сообществу Verband der Hersteller Digitaler Modellbahnprodukte e.V - VHDM (Ассоциация производителей цифровых железнодорожных моделей) известному так же как RailCommunity. Сообщество как раз и было создано для наведения порядка в стандартах, нормах и регламентов DCC. В него вошли как Lenz, так и практически все ведущие европейские производители жд модельной электроники, а также MOROP и NMRA. В итоге в конце 2016 году в рамках стандартизации норм опубликовали окончательную редакцию - RCN-217, которая и является действующей на сегодняшний момент спецификацией RailСom.
Фактически S-9.3.2 никогда не действовал, но не по причине наличия отметки UNDER REVISION (она появилась лишь в 2015 году зачем будут описано ниже) или отсутствия формального утверждения в NMRA, а по тому что его никто и никогда его не использовал. А вот почему, на это есть ряд факторов: «война Ленца», низкое или даже скорее отвратительное качество S-9.3.2 в части перевода его на английский язык - по этой причине немецкий язык остался в описании, крайне высокий бюрократизм в NMRA – утверждение и принятие норм может проходить годами, кроме этого, так-как американским производителям RailCom совсем не интересен, а все европейские производители, использующие Railcom говорят на немецком то им S-9.3.2 и не нужен вовсе, они использовали оригинальные спецификации Lenz. Кроме этого в ходе разработки новых норм RCN внутри VHDM компании сотрудничали друг с другом в том числе и в вопросах Railcom, как пример функция QoS была реализована благодаря Вольфгангу Кюферу из OpenDCC. Фактически игнорирование RailCom закончилось где-то 2015 году при выходе спецификации Lenz 1.4, а полностью «Война Ленца» окончилась в 2016 года, когда после нескольких просрочек оплаты патентного сбора, патент Lenz был аннулирован и опубликованы нормы RCN-217.
И об S-9.3.2. Так как NMRA входит в VHDM то они конечно были в курсе переработки спецификации, по это причине в 2015 году и появилась отметка UNDER REVISION, но для принятия решения о пересмотре требуется собрание и согласие всего директората NMRA, а это обычно очень не быстрый процесс, иногда длящийся годы, что и было одной из причин создания норм RCN, выход которых поставил точку в том, каким должен быть RailCom.
По причине что все компании, выпускающие оборудование с поддержкой RailCom состоят в VHDM либо тесно с ней сотрудничают, то продукты выпущенные ими в поседение 2-3 года соответствуют нормам RCN-217, так как они имели к нем доступ еще до официальной публикации.
В результате оборудование имеющие RailCom должно соответствовать как минимум спецификации 1.4 от Lenz имеющей полную совместимость с RCN-217, а при разработке новых продуктов необходимо использовать только RCN-217.
И пару слов о нормах RCN они были созданы для максимально возможной совместимости всех имеющихся на рынке продуктов электроники в жд модельном сегменте. До введения RCN производители использовали нормы RP и S для DCC и NEM для интерфейсов, но NMRA слишком не поворотлива, а многие нормы MOROP устарели. VHDM уже выпустило RCN по четырём интерфейсам декодеров и пересмотрели многие нормы DCC, их придерживаются даже те производители, которые не входят в VHDM, например D&H и OpenDCC.
В установлении истины в данном вопросе мне помогли Арнольд Хюбш (Arnold Hübsch) – один трех представителей совета VHDM, Вольфганг Куфер (Wolfgang Kufer) – из OpenDCC, службы поддержки D&H и Zimo, за что им всем огромное спасибо.
Первая спецификация BiDi была разработана Lenz в начале 2000-ых. Проблема была в том, что Lenz не хотел её бесплатно делиться, но при этом хотел, чтобы все использовали именно её. При этом у Zimo был свой взгляд на системы обратной связи в декодерах, они разработали свой протокол BiDi в 2000 году.
Lenz оформил патент на свой протокол причём как в Германии, так и в США и передал спецификация в NMRA что решало вопрос об их использовании сторонним производителями, где она получила статус регламентного предписания RP-9.3.1 и RP-9.3.2 и была опубликована в 2003 году, началась «патентная война Ленца». Позже спецификации были откорректированы RP-9.3.1 в 2007 году, RP-9.3.2 в виде драфт версии вышла в 2005 и просуществовала до 2012.
Но сообщество производителей ЖД модельной электроники не одобрили поведение господина Ленца, единственной системой с поддержкой RailCom была продукция его главного конкурента - Zimo, станция MX31ZL ставшая первым коммерческим продуктов с RailCom в мире.
В начале 2010-ых ESU заинтересовалось темой RailCom, для его реализации в своих новых разработках, в результате этого сотрудничества у Lenz родилась новая кардинально пересмотренная спецификация RailCom, получившая номер 1.2. На основе этой пересмотренной спецификации в NMRA разработали уже стандарт S-9.3.2 от 2012 года, фактически опубликованный в 2013. Указанный стандарт заменял собой RP-9.3.1 и RP-9.3.2, так как описывал как физическую часть, так и протокол в одном документе.
Но производители не стремились к реализации Railcom в своих продуктах, «Война Ленца» продолжалась. Ситуация изменилась благодаря образованному в 2009 году сообществу Verband der Hersteller Digitaler Modellbahnprodukte e.V - VHDM (Ассоциация производителей цифровых железнодорожных моделей) известному так же как RailCommunity. Сообщество как раз и было создано для наведения порядка в стандартах, нормах и регламентов DCC. В него вошли как Lenz, так и практически все ведущие европейские производители жд модельной электроники, а также MOROP и NMRA. В итоге в конце 2016 году в рамках стандартизации норм опубликовали окончательную редакцию - RCN-217, которая и является действующей на сегодняшний момент спецификацией RailСom.
Фактически S-9.3.2 никогда не действовал, но не по причине наличия отметки UNDER REVISION (она появилась лишь в 2015 году зачем будут описано ниже) или отсутствия формального утверждения в NMRA, а по тому что его никто и никогда его не использовал. А вот почему, на это есть ряд факторов: «война Ленца», низкое или даже скорее отвратительное качество S-9.3.2 в части перевода его на английский язык - по этой причине немецкий язык остался в описании, крайне высокий бюрократизм в NMRA – утверждение и принятие норм может проходить годами, кроме этого, так-как американским производителям RailCom совсем не интересен, а все европейские производители, использующие Railcom говорят на немецком то им S-9.3.2 и не нужен вовсе, они использовали оригинальные спецификации Lenz. Кроме этого в ходе разработки новых норм RCN внутри VHDM компании сотрудничали друг с другом в том числе и в вопросах Railcom, как пример функция QoS была реализована благодаря Вольфгангу Кюферу из OpenDCC. Фактически игнорирование RailCom закончилось где-то 2015 году при выходе спецификации Lenz 1.4, а полностью «Война Ленца» окончилась в 2016 года, когда после нескольких просрочек оплаты патентного сбора, патент Lenz был аннулирован и опубликованы нормы RCN-217.
И об S-9.3.2. Так как NMRA входит в VHDM то они конечно были в курсе переработки спецификации, по это причине в 2015 году и появилась отметка UNDER REVISION, но для принятия решения о пересмотре требуется собрание и согласие всего директората NMRA, а это обычно очень не быстрый процесс, иногда длящийся годы, что и было одной из причин создания норм RCN, выход которых поставил точку в том, каким должен быть RailCom.
По причине что все компании, выпускающие оборудование с поддержкой RailCom состоят в VHDM либо тесно с ней сотрудничают, то продукты выпущенные ими в поседение 2-3 года соответствуют нормам RCN-217, так как они имели к нем доступ еще до официальной публикации.
В результате оборудование имеющие RailCom должно соответствовать как минимум спецификации 1.4 от Lenz имеющей полную совместимость с RCN-217, а при разработке новых продуктов необходимо использовать только RCN-217.
И пару слов о нормах RCN они были созданы для максимально возможной совместимости всех имеющихся на рынке продуктов электроники в жд модельном сегменте. До введения RCN производители использовали нормы RP и S для DCC и NEM для интерфейсов, но NMRA слишком не поворотлива, а многие нормы MOROP устарели. VHDM уже выпустило RCN по четырём интерфейсам декодеров и пересмотрели многие нормы DCC, их придерживаются даже те производители, которые не входят в VHDM, например D&H и OpenDCC.
В установлении истины в данном вопросе мне помогли Арнольд Хюбш (Arnold Hübsch) – один трех представителей совета VHDM, Вольфганг Куфер (Wolfgang Kufer) – из OpenDCC, службы поддержки D&H и Zimo, за что им всем огромное спасибо.