自動車の電子制御用OSを日本メーカー共同で独自開発 78
ストーリー by yoosee
前時代的な空気を感じてしまわないでもないんですが 部門より
前時代的な空気を感じてしまわないでもないんですが 部門より
あるAnonymous Coward 曰く、
読売新聞に 経済産業省と自動車メーカー10社と共同で自動車の電子制御用OSを開発という記事が掲載されている。 次世代にむけたElectronic Control Unitの制御用OSということのようで、 ようするに経産省が予算をつけてJasParの枠組みで共同開発する話のようだ。 以前には日経から トヨタが自動車搭載用の標準ソフトウエアを独自開発というネタが出ていたが、JasParということはこの絡みもあるのかもしれない。
読売では、PC世界でのWindowsに対抗する日の丸OSという構図を持ち出して、既にISO17356にもなっている OSEK/VDX 仕様への対抗的な動きのように書かれているが、 AUTOSARも巻き込んでの主導権争い的な政治的側面が強いようにも思える。 全く独自の仕様と実装を一から作るという可能性はさすがにないような気がするが、どうだろうか。 TOPPERSプロジェクトでOSEKカーネルが作られていたりしているが、 このあたりの人々で情報をお持ちの方がいたら教えていただければ幸いだ。
私が知っている話と同じなら… (スコア:5, 参考になる)
Autosar以降,ソフトウェアの静的コンフィギュレーションが顕著になって,ツール無しにはOSが語れなくなってきています.
OSEKのOIL,μITRON4.0仕様の静的APIを知っている人は,その延長線上だと思ってもらえれば概ね正解です.
この辺りの事情を知っていれば,「Embedded Linuxなら!」とかいうコメントが論外なのはもちろんのこと,設計的に動的であるT-Kernelに出番がないことも判るでしょう.
既にコメントがある通り,JasParとTOPPERSは,会員が割と被ります.
しかし,今回の枠組みでは,狭い意味でのカーネル屋さんたちはメインストリームではありません.
// コレくらいの上っ面解説ならIDでも許されるよね?
from もなか
TOPPERS/OSEK開発者による解説 (スコア:4, 参考になる)
http://www.kumikomi.net/article/explanation/2005/03osek/01.html [kumikomi.net]
Re:TOPPERS/OSEK開発者による解説 (スコア:2, 興味深い)
ECUを使い切るような形で書かれているリアルタイム性ばりばりの
ソフトウェアを、一個のプロセサに集約するのは激しく難しいですよね。
自分の中のスレッド群の優先順位は読み切っていても、それにほかの
スレッドが絡んでくると、ホントにリアルタイム性が保証できるか
難しいですよね(というか、単純に足し算をするだけだと無理でしょう)。
というわけで、どうやって[既存]のソフトウェアモジュールを救うのか、
それとも[無理だからプログラムは全部作り直しじゃ]とさっさと宣言するのか
興味津々であります。
でも一番難しく、かつ興味深いのは、
「OS(TRONみたいなモニタじゃないよ)とはナニカ」
ということを、リソース使い切り型の無手勝流プログラムを書いていた
人たちにどうやって教育するのだろうということですね。
// ユーザランドでスピンロックをすると言う事の意味を
// 教えるのに激しく苦労したのでAC
T-engineでいいじゃん。 (スコア:4, 興味深い)
マジすばらしんだけど。
http://ja.wikipedia.org/wiki/T-Engine [wikipedia.org]
みんな幸せになればいいのに
散歩師:漫画居士柴岡秀一
http://www.toheart.to/%7Emanga
Re:T-engineでいいじゃん。 (スコア:1)
Re:T-engineでいいじゃん。 (スコア:4, 参考になる)
さらに,マルチメディアOSを研究しているNCESは,TOPPERSプロジェクトとも一定の距離を置いたプロジェクトとして運営されています.(関わっている人はカブっていますけれど…)
BTRON系のトロン厨な皆様には耳障りがわるいかもしれませんが,T-Kernelは車載においては数歩出遅れていると(少なくとも現時点では)言えると思います.喧伝されたカーナビプロジェクトも数年後には(ry
// "車載に於いても",なんてキツいことは言わない紳士なID
from もなか
どんなに使いやすくても (スコア:4, 興味深い)
とてもじゃないけどOSなんて載せられないような性能(ROMないRAMないスピードない)の
MCUで、超重要な部分(もろ人命に関わる)の制御やらせるなっての!
確かに、そんな重要な部分なら、ブラックボックスが発生するようなOSに依存できないってのは
あるけれど、それならグレードけちってトリッキーな処理をやらざるを得ないような状況に
もってくってのはどうよ。
特に低コストを売りにするような製品なのに、ソフト共通化を謳ってメインストリームと
同様の処理体系にさせるんじゃねえ!
メインストリームの方は、溢れるリソースに胡座かいたような設計になってんだよ!
そんな処理をこっちにやらせようとするんじゃねぇっての!
#とてもじゃないけどIDにできないのでAC
Re:どんなに使いやすくても (スコア:1)
今のエンジンとかのクリティカルな部分の処理レスポンスって、ms単位を割ってμs単位かそれ以下の応答速度で的確な処理を行う部分がままあって、その処理の入力要素も出力要素も計算式も複雑になってるのに、そういう部分からコストダウンで処理能力が低いMCUにされがちなのを嘆いているのでは。
例えばMIPS系やPPC系やなどのRISCコアで100MHzのクロックで安定したレスポンスや性能がやっと出せる処理を、30MHz程度のCISCコアでやらせたり、16MHz程度のZ80/8085/6809ベースのコアでやらせたらどうなるよ?って事でしょ。
あとは、オンチップRAMが小さいの(64Kとか32Kとか)に、オンチップRAM/ROMだけでソフト組めとか…
実際、そういう要求が、ソフト側の事情抜きでハードウェアの仕様策定の段階で固められていることって、結構多いと思いますよ。
実際問題どこまで汎用化できるのだろう? (スコア:3, 興味深い)
そういうところは独自モジュールの追加で対応とかにするんですかね?
海の向こうじゃボッシュみたいな企業があったり
BMWとプジョーグループでの共同エンジン開発みたいなことが比較的良くあるものの
日本じゃ車両単位のOEMが多くて大分ベースが違いますよね。
(ただ海外にしたってVWのDSGみたいのが汎用機器で制御されているとは考えにくいから、
ミソは独自部分の追加しやすさになったりして?)
だから自動車メーカーと共同というよりは
ボッシュみたいな会社を共同立ち上げてそこで開発するのもありではないかと。
でもって失敗したら会社ごと見捨てると(をい)。
Re:実際問題どこまで汎用化できるのだろう? (スコア:3, 参考になる)
日本のすべての自動車メーカーが自前で制御開発をしてる訳が無いでしょ。ボッシュほど前面に出てこないだけで、実際の制御はデンソー・日立・三菱なんかがやってる。制御ロジック自身はパテントの問題があるんであまり使いまわしは効かないだろうけど、OS(というほど汎用的なAPIを持っているのかどうかは良く知らないけど)は、それぞれのメーカー単位ではある程度共通なはず。ハードウェア側のインターフェースは現状CANでほぼ統一されたんで、共通化できる部分はそれ以前よりも格段に増えてるはずだし。
要するにカーナビのように、制御機器に求められる機能やデータの処理量が増えてきたので、各社が自前でやるのは非効率的だから統一しましょ、というのが今回の話じゃないかと。ぶっちゃけ、OSコアは何でもいいからミドルウェアを統一したい(=どうせ制御用のソフト自体は統一できっこないから、APIを整備して開発効率を上げたい)ってのが本音のような気がします。
Re:実際問題どこまで汎用化できるのだろう? (スコア:1)
Re:実際問題どこまで汎用化できるのだろう? (スコア:1)
船は山に登るか? (スコア:2, 興味深い)
で、そのメーカは自動車メーカーで一番発言力がありそうな雰囲気なんですよね…。
仕様に関して話がまとまるのか否か、非常に心配です。
でかいものだと、品質はどうするの? (スコア:1)
どんなOSでも、もともと組み込み向けではない、肥大化したOSよりはましなんでしょうが、自分が運転する車に搭載されるかと思うと、少し使いにくいものでも、安定感のあるOSのほうが安心できますね。ぜひぜひ、欧米以上の組み込みOSを作っていただきたいです。
# 携帯電話のOSは、組み込みTRONがよかった……。
All your base are belong to us
Re:でかいものだと、品質はどうするの? (スコア:0)
今も多くがTRONを使っていますよ。
リアルタイム性の必要ないアプリ用のCPUでは使われなくなりましたけどね。
Re:アプリ? (スコア:0)
このフレーズの意味がわからないんだけどさ。ちょっと説明して。
Re:アプリ? (スコア:1, 興味深い)
>このフレーズの意味がわからないんだけどさ。ちょっと説明して。
全然組み込み屋でもなんでもないんだが、
今の携帯とかCPU複数持ってて、電話の機能みたいなリアルタイム性を
要求するアプリと電卓みたいなノンビリユーティリティがあって
実行するCPUが違ったりするじゃないですか。
で、そいつら全部同じOSで動いているんじゃなくて
リアルタイム性を要求する電話用のCPUはTRONで管理する、とかあるんじゃないですか?
他のはLinuxだったりとか。
コクサンじゃだめ? (スコア:1, 参考になる)
協調学習並列化そして個性の獲得 (スコア:1, おもしろおかしい)
Re:協調学習並列化そして個性の獲得 (スコア:1, おもしろおかしい)
まだかかれてない? (スコア:1)
それなんて Hyper Operating System
#HOS は篠原製だから今回のは LOS かな
#もう HOS ネタはいいって?だってパトレイバー好きなんだもん
そして数年後... (スコア:0)
Re:そして数年後... (スコア:0)
Re:そして数年後... (スコア:0)
シグマか・・・ (スコア:0)
いやもう目を背けたくなるくらい異臭を放つ汚物であることは確かなんですが。
過去にこんな失敗があったんだと知らない連中が、同じ轍を踏みそうな空気がバンバン流れてきてるので。
ええ。すっごい身近にも。
# 同僚に見られても別に構わないけど一応義は通したいのでAC
アア、ウツクシイ國 (スコア:1, おもしろおかしい)
同感なんだけど、そうすると、
- シグマプロジェクトはプログラマの『単独犯』
- 関係者が『自殺』
- 突如脱税容疑で警察の取り調べが入り、責任者が逮捕され有罪判決
- 法改正を受けてコレまでと同じ仕事ができなくなり倒産
#他に「銃刀法違反」と「痴漢の現行犯」も使えるな。
#木の葉を隠すには森の中。警察は毎日森を作るのに大忙しだ。
ということが多発しそうなので、この国では無理でしょう。
Re:アア、ウツクシイ國 (スコア:1)
BABEL BABEL BABEL BABEL ...
国産は既にあるじゃないか (スコア:0, 参考になる)
Re:国産は既にあるじゃないか (スコア:2, 参考になる)
Re:国産は既にあるじゃないか (スコア:2, 興味深い)
# というかハードリアルタイムはカーネルだけでどうにかなるもんでもない。
Re:国産は既にあるじゃないか (スコア:0)
Re:国産は既にあるじゃないか (スコア:2, すばらしい洞察)
プリミティブを好き勝手、統一感も無しに使えるのが、いけないんだい。
正しい制約を持った統一ルールは、自由を与えてくれる。
あ、プリミティブしかないのがいけないのか...
う゛ぁか役人 (スコア:0)
3、40年前からずっとそんなこと云ってるが
その「日の丸ほげ」で global standard になったものがなにかあるのかと
Re:う゛ぁか役人 (スコア:1, すばらしい洞察)
#グローバルぢゃねーし
Re:う゛ぁか役人 (スコア:1)
Re:う゛ぁか役人 (スコア:0)
一部の方々は潤うわけです。
「日の丸ほげ」で global standard (スコア:0)
Re:「日の丸ほげ」で global standard (スコア:1)
# KAIZEN かなぁ?
HENTAI とかだったら、嫌だなぁ。
fjの教祖様
もうART-Linuxでいいよ (スコア:0)
Re:もうART-Linuxでいいよ (スコア:1)
Re:/.Jで組み込みの話をしても無駄 (スコア:0)
下請けソフトウェア要員は/.Jにたくさんいると思うけど、
ハード側はちょっとね・・・。
# 「組み込みを知らなきゃ馬鹿」とは全く思わんけど
Re:/.Jで組み込みの話をしても無駄 (スコア:1, すばらしい洞察)
知らないくせに知ったかぶりを吹かすから馬鹿といわれるのだ
Re:/.Jで組み込みの話をしても無駄 (スコア:1)
(テストとでバッグとちょこっとだけコード書かせてもらえた)
全く世界が違ってためになったと思う
二度とやりたくないけど
Re:/.Jで組み込みの話をしても無駄 (スコア:0)
フレームの元がついているが、元コメントは「PCが業界の全てではない」と言いたいんじゃないかと。
Re:/.Jで組み込みの話をしても無駄 (スコア:1, 興味深い)
アセンブラで書いても別に難しく無いレベルの開発に、リアルタイムOSとCコンパイラが無いと開発不可能、なんて言い出す人達が増えてきたこの頃になって特に。
微妙な制御を行う時は、隠蔽されるものが少なければ少ないほど楽だったりする事も多いんだけどね。
Re:/.Jで組み込みの話をしても無駄 (スコア:1)
そもそも、情報処理系の学科だと特に、計算機工学とか言う科目でも、座学だけって感じですからね。
要求されていることをアルゴリズムに落とすあたりの教育もどういう状況だか。って感じですし、昔みたいにトランジスタやゲートから実際に弄って、回路のツボみたいなあたりを皮膚感覚で掴んでいる人が激減しているような気もしますし。
組み込みの場合には、本気でやるならMCU/MPUの内部構造のブロック図を読めないとハードもソフトも書きようがないですから、最低でもハードとソフト両方読めないととりあえずの物はかけてもデバッグで難儀しますから…分業化の弊害もあるんでしょうけど。ハード担当とソフト担当の共同作業での開発工程にしないあたりの。
まぁ、アセンブラ使うのが必ずしも正義とも思えませんが。
アルゴリズムをしっかり組めるならば、RTOSはいらなくてもCで記述した方が可読性が良くなりますからね。
EndianとかWord Sizeとか構造体とかでハマるくらいだったら最初からアセンブラで…と言うのは半分同意しますが、基本的にはMCU/MPU依存の部分以外はcで書けるならば書いてしまった方が大半をアセンブラで書いてしまうよりも圧倒的にバグを作り込み難い所までC言語コンパイラの能力が上がっていることは確かですから。経験上の話に過ぎないですけど。
どっちで書くにしても、IDEなどを安易に使うのは、実はあまり良くないのかも。
既存の低レベルライブラリやスタートアップコードの利用でメインの部分を抽象化しまくれる利点はありますけど、トラブった時に所在がハードかソフトか見極めるのに手間取りますし。
Re:/.Jで組み込みの話をしても無駄 (スコア:1)
それってソフトウエア業界(或いはプログラマ)全体では?orz
そうともいえんぞ (スコア:0)
OS も怪しいな。
せいぜい開発環境のライブラリとバッドノウハウを少々ってとこか。
Re:/.Jで組み込みの話をしても無駄 (スコア:0)
Re:/.Jで組み込みの話をしても無駄 (スコア:0)
組み込みに対してLAMPな尺度でしゃべって、それがおかしいことに全く気がつかない奴が多すぎ。
まともに組み込みの話をするとこういうバカどもが「それはおかしい」といってきて話が進まん。