?

Log in

No account? Create an account
Записки ироничного джентльмена
Мы джентельмены если есть удача...
Китайские машины. 
14th-Jan-2014 11:56 am
Default
Камент получился слишком длинный, так что я решил его вывесить отдельным постом.

Китайский автопром можно и нужно воспринимать всерьёз, но не поэтому, что китайско-израильское Qoros 3 получило 5 звёздочек в европейских краш тестах.

Для начала Китай самый быстро растущий рынок и кроме того уже вроде бы официально самый большой по количеству продаваемых ежегодно автомобилей. Во вторых многие крупные конторы уже наладили там не только сборку автомобилей, но и производство запчастей. В третьих иностранные фирмы не владеют своими заводами в Китае, каждый иностранец обязан скооперироваться с местными производителями. То есть реально в Китае уже практически отстроена огромная производственная база, которая пока работает на Китайский рынок.

Но учитывая особенности китайского рынка больше всего стоит переживать АвтоВАЗу и Тате когда китайцы пойдут на внешний рынок в первую очередь они сожрут нишу этих ребят.

Более того Great Wall уже бороздят российские просторы, но пока люди привыкшие в АвтоВАЗу отзываются о китайский машинах матерно.
Comments 
15th-Jan-2014 09:34 pm (UTC)
А всем этим добром заведует центральный.... исходя из необходимости возможности прошива любого блока на станции тех. обслуживания через порт диагностики. ;)

Я несколько месяцев назад столкнулся с тем насколько всё стало интегрировано, у меня был практически разрыв шаблона.
15th-Jan-2014 09:36 pm (UTC)
Для удаленной перепрошивки с помощью центрального блока или без нее иметь высокоскоростную шину не требуется. Другое дело, если действительно все в одном блоке, но какой в этом практический смысл, если учесть наличие разных комплектаций и, соответственно, наличия/отсутствия тех или иных контроллеров.
15th-Jan-2014 09:42 pm (UTC)
Центральный код должен считывать параметры со всех систем... память конечно у всех своя......... я начинаю понимать, почему "индийские программисты", но ведь кто-то должен был написать программу которая это всё собирала вместе....
Возможно та программа не собиралась путём, "вставим этот код вод для этого", а этот "вот для этого" практически для всего нужны системы обратной связи, код должен учитывать угол поворота колёс при выборе расчётной передачи. А не получиться ли у нас как раз индуский код если собрать в кучу куски кода написанных разными конторами с разными принципами?
15th-Jan-2014 09:59 pm (UTC)
Да не надо почти ничего собирать вместе, за редким исключением, и далеко не везде вообще взаимосвязь нужна. Основная причина для внедрения CAN в автомобилях - провода сэкономить. Чтоб к каждой фаре, к каждой лампочке не тянуть сигнальный провод, тянут всего один, зато втыкают не в цоколь лампочки, а в "умный" выключатель этой лампочки, при этом весь интеллект выключателя заключается в том, чтобы отобрать из приходящих по шине пакетов тот, который адресован именно ему, и вытащить оттуда команду на включение. Это вовсе не означает, что тут есть причина для организации какого-либо доступа в память удаленного выключателя или хотя бы обратной связи. И так везде - датчик уровня топлива в баке рапортует об уровне с определенной периодичностью, датчик дождя - о наличии дождя. Все это бегает по шине и нет никакой нужды это даже централизованно маршрутизировать - это же шина, а не точка-точка. Каждый блок, который к ней присосался, возьмет свое, а чужое проигнорирует. Ничего нового, принцип ethernet'а в том виде, в котором он когда-то родился.

Понятно, что блоки, непосредственно участвующие в управлении автомобилем - компьютеры управления двигателем, коробкой, ABS, системами стабилизации и проч. - они ведут более интенсивный обмен, причем по отдельной шине обычно, но протокол обмена известен и опять же тут нет ничего нового - все это мульярды раз реализовывалось за десятилетия развития вычислительной техники и компьютерных сетей. Зачем нам куда-то собирать "куски кода, написанные..." - эти куски кода или смогут работать вместе, обмениваясь информацией по определенному протоколу, или не смогут, третьего не дано.

В случае с Тойотой речь как раз шла о внутреннем устройстве одного отдельного контроллера, насколько я помню, он был просто совершенно безграмотно и безответственно спроектирован и написан.
16th-Jan-2014 02:39 am (UTC)
В том случае о котором до меня дошли слухи и который поймали до запуска с производства "возьмет свое, а чужое проигнорирует" не сработало, и один блок при определённых параметрах посылал об общей шине сигнал напрочь вырубавший другой блок....

//В случае с Тойотой речь как раз шла о внутреннем устройстве одного отдельного контроллера, насколько я помню, он был просто совершенно безграмотно и безответственно спроектирован и написан.
Что не отменяет факта что Тойота не предусмотрела такого варианта, и более того не имела в протоколах какого либо способа обнаружить это г.

Кстати, вот здесь поставщика вообще не упоминают, а пишут только про Тойоту. И кстати упоминают и то о чём я говорил, что написано, так что stack overflow вполне мог быть... Учитывая насколько редко эту педаль клинило, я бы лично на stack overflow бы всё и списал.... если оно постоянно писало куда хотело, то что-то могло и написать туда где было положение педали.
http://www.eejournal.com/archives/articles/20131127-toyota/
16th-Jan-2014 07:25 pm (UTC)
> и один блок при определённых параметрах посылал об общей шине сигнал напрочь вырубавший другой блок....

Причин этого может быть много, в том числе и в приемном блоке.

> Что не отменяет факта что Тойота не предусмотрела такого варианта, и более того не имела в протоколах какого либо способа обнаружить это г.

Безусловно.

> Кстати, вот здесь поставщика вообще не упоминают, а пишут только про Тойоту. И кстати упоминают и то о чём я говорил, что написано, так что stack overflow вполне мог быть...

Ну, stack overflow - это все-таки не запись в чужую память.
16th-Jan-2014 07:41 pm (UTC)
//Ну, stack overflow - это все-таки не запись в чужую память.
Хммм... а что? Я был уверен, что stack overflow это когда программа пишет в память вне место отведённого для этого операционной системой. Что в общем то не страшно, при условии что оно не записывает поверх чужих данных, которые туда были записаны с разрешения операционной системы.
16th-Jan-2014 07:49 pm (UTC)
Нет, это ровно то, как оно и называется - переполнение стэка. Следствием этого может являться как аварийное завершение программы, так и успешная запись в "не ту" память.

https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D0%BA_%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D0%BE%D0%B2


Edited at 2014-01-16 07:50 pm (UTC)
16th-Jan-2014 07:54 pm (UTC)
// запись в "не ту" память.
Именно это я и имел в виду. Если верить той статье то анализ показал использование до 92% памяти в то время, как тойотовские ребята считали что там не больше 50%. Думается мне, что это наиболее вероятный ответ, потому как если бы что-то было в алгоритмах, они бы таки это откопали при проверке.
Хотя конечно, я человек довольно далёкий от программирования, и вообще маску на стройке нашёл.
16th-Jan-2014 08:00 pm (UTC)
> потому как если бы что-то было в алгоритмах

Так ведь stack overflow на ровном месте не случается, это вещь всегда рукотворная.
16th-Jan-2014 08:07 pm (UTC)
Я исхожу из того что я видел... в мою бытность в универе, в мою обязанность младшего помошника эникийщика входило обходить утром лаборатории и проверять компьютеры. Каждое утро я там обнаруживал две или три синенькие NT, я их перезагружал, на следующие день синели опять две или три машины, но уже на следующих компьютерах. Когда лабы за апргейдились до Вынь2к синенькие машины практически исчезли, а когда появлялись в большинстве случаев означали умирающее железо.
И из рассылок freebsd "срочно пчтесь, в sendmail обнаружен очередной buffer overflow, с потенциальным получением прав админа"

16th-Jan-2014 08:48 pm (UTC)
Ну так а в чем портиворечие - синий экран смерти обычно вызван ошибками в ОС или драйверах.

А buffer overflow и stack overflow - таки немного (или много) разные вещи. В общем случае непонятно, какой адрес окажется в стэке в момент его переполнения и кому он принадлежит, поэтому эта ситуация уявзвимостью не считается. Переполнение же определенного буфера (области памяти) в программе - вещь исследуемая и предсказуемая, потому что перепоняется буфер в нашей собственной программе, а не в чужой, соответственно, ОС не предпринимает никаких действий по защите (она резонно считает, что со своей памятью программа должна сама разбираться). Поэтому достаточно изучить, где в скомпилированной программе какой буфер и как далеко после него находится какой-нибудь исполняемый код. Дальше готовится код, который туда нужно поместить (который будет что-то делать, нужное нам) и генерируется последовательность данных, которая и засылается в атакуемый sendmail, который, в итоге сам себя модифицирует тем, что ему прислали, и передает в эту область кода (уже чужого) управление.

Знаменитый червь Моррисона именно это и использовал. Почти 30 лет прошло, а до сих пор не вымерли программисты, которые не проверяют длину принимаемых/пересылаемых данных. Повбывав бы. :)
16th-Jan-2014 08:53 pm (UTC)
//до сих пор не вымерли программисты, которые не проверяют длину принимаемых/пересылаемых данных. Повбывав бы. :)
А почему ты так уверен, что в случае с тойотой собака порылась не там?
16th-Jan-2014 08:54 pm (UTC)
Да не, не уверен. А что это меняет? Рукотворная ошибка, все-равно ж.
This page was loaded Jun 16th 2019, 5:07 pm GMT.