私の会社生活の最初の１５年ほどは、

ソフトウェア構造＝モデル構造、アーキテクチャの追求に明け暮れた

と言って良いかもしれない

2011年　講演資料から

2022年　MotorFan  マツダ資料から

私が手がけた

ソフトウェアの対象範囲は、だいたい次のように広がっていった

１）半導体周りのBASEソフトウェア開発＠並列計算コンピュータハード開発

２）エンジン制御のリアルタイムOS開発

３）制御システムを組み立てる　５０個のレゴブロック関数（アセンブラ版）

４）エンジン制御／駆動系制御／車両制御の制御プログラム開発

５）環境モデル、人間モデル、テストモデル、評価モデル

６）車一台分のシミュレーションモデル開発

もちろん　いずれも　ソフトウェアです

いずれも　アセンブラ言語、C言語、MATLAB言語で

自分でつくってきました、

そして、長期連休には、

そのソフトウェア構造を再構築して、究極の開発効率となるように、みがいてきた

超変人の　チームリーダーだったと思う

チームメンバーが　つかう　車一台のシミュレーションモデル＝ソフトウェアを、　

連休のたびに徹夜で再整備して、

連休明けの初日には完璧にソフトウェア構造再整備したモデルを配った

表面的な動きはメンバーには同じ。構造だけが変わっている。

なぜが仕事が楽になる。なぜか品質が良くなる。バグが出ない。

その苦行は、正月休み、5月連休、お盆連休、、、と繰り返された

ほぼ、クレイジーなこだわりだった

2012年に雑誌掲載した記事に詳しい

マツダで、エンジン制御用の Rapid-ECU を完全内製で開

発したのは、1987 年であった。複雑に見える ECU の周辺

回路も分析すれば、10 種程度の入力回路 & 出力回路に整理

でき、これをあらかじめ備える構成とした。マイコンボー

ドも内製である。これとセットで、制御用言語の開発も内

製で行った。50 種ほどの関数（現在でいう関数アイコン）

の組み合わせだけで、自由にエンジン制御を開発出来る環

境を構築した。この MBD ツール群は、FICCS と呼ばれ、

1991 年に量産された RX7（FD3S 型 ロータリーエンジン）

の技術開発から活用された。

この制御ソフトの開発環境は

たった５０個の関数のみ　をつかって、

　（のちの時代に、レゴブロック関数　と呼ぶわけですが）

　　　エンジン制御でも　ブレーキ制御でも　駆動系制御でも　車両制御でも

　　　　　　　自由に組み立てることが可能

本当に５０個のレゴブロック関数しか使わない、

一行もプログラムを書かない

１）品質も効率も上がる理由は

　仮に1つのレゴブロック関数が１０００行のプログラムで構成されると仮定すれば　

　人間が１０００行のプログラムを書くことに比べて、１０００倍早い

　５０個の関数の　品質だけ高めておけば　いくら組み合わせて使おうとも　品質は破綻しない

　それでいて

　５０個の関数　のみで全ての新技術を　生み出すことが可能

２）仕様変更への対応力

　　たとえば、ある制御システムの計算周期を、

　　32msec毎から16msec毎へ丸ごと移動させる場合、

　　例えば、５回分のデータを平均化して滑らかにする、過渡動作の意味が変わる

　　こんな処理は、制御システムの中には無数にある

　　普通のソフトウェアの作りですと、

　　計算周期を変えると、仮に1000箇所以上の修正をしないと動かない

　　１箇所間違えたら、品質問題となる

　　　一方、

　　レゴブロックの場合、過渡の矛盾は、５０個の関数の中で自動整合をとれる

　　こんなソフトウェア大変更でも　人間は何もしなくても　過渡応答特性は全く変わらない、

　　そもそもその変更点すら最初から存在しないから

　　品質問題は起こらないし、開発工数も発生しない　

これが究極でしょう！

　それを、

本当の実車開発環境でもシミュレーション環境でも　同じレゴブロック　で動かすのです

これらの技術は　洗練された　究極アーキテクチャ　が勝負です

1987年に

この開発環境を自作して仕事をやっていた

Simulink がその後に実現した世界を、もっと洗練された形で実現していましたことになる

この年代は、今では有名なツールメーカーMathworks(1984創業)やdSPASE(1988創業)も　

    ほぼ、未熟or誕生前　状態

その後も

こんなことを、新しい分野でどんどん進めてきた私

なので

i-Modelsは

車のシステム要求↔︎ソフトウェア機能↔︎エレキアーキ機能↔︎︎半導体機能

　　これら車一台分の技術を　シンプルモデルで　繋ぐことができる

　　　　車のシステム要求　から　半導体まで　繋ぐことができる　

　　　　　　　　超稀有天然記念物級　コンサルタントです　と申し上げております

プログラムだけの一流エンジニア、エレキアーキだけの一流エンジニア、、、、、

それぞれは　たくさんおられると思いますが

私の変人ポイントは、

　　車に搭載される　全てのハード＆制御分野を　上下左右で、熟知していることです

　　　　全体がわかっているから、機能を抽象表現してシンプルモデルで繋ぐことができると言うこと

たとえば、

①システム要求の変更点　→②ソフトウェアの演算量変化　

　　→③エレキアーキでの電力消費 →④AI頭脳半導体の温度変化　

　　　　まで　モデルで予測 可能です

近年の

巨大システムを開発している日本企業内での開発環境を考えると、

分業化が進み、一人で全部を経験できません

たとえば、制御の大分野が１０あったとして

多くは1つしか経験できません。一部の限られたエンジニアで２−３分野把握。

優秀なエンジニアが５名ほど集まらなければ、

巨大システム全体の制御は、説明できない時代です

１つにつながらない行き違いは、さまざまな問題を生みます、品質問題、手戻り、重複開発、、

（全システム見ると　重複部分が　軽く半分以上に見えます。

　そんなはずはない、とおっしゃる専門家の皆様、ADASとCONNECTIVITYで、

　　同じレゴ関数で開発できるであろう可能性を考えれば容易に説明できることです）

ツール面を考察してみましょう

複雑なまま表現するツールメーカーは、部分部分では存在しますが、それらはほぼ垂直統合であり

横方向に、これだけの　他分野技術を　繋ぐことができるのは見たことがありません

それぞれの分野毎に　いろんな詳細ツール、これら垂直統合型ツールでは

全体のつながりが全く見えないのです

繋ごうとすると、重くなり、扱う入力パラメータは爆発的に増え、手に負えない

AIを使おうにも、全体がわかっていない人は、適切な指示をAIへ出せない

複雑系システムを扱うことになった　現場のエンジニアは　

もっとシンプルに　全体を繋いで見渡せる手段　を　欲しておられる

と思います

もう一つ申し上げます

車の開発だけではありません

その対象物が　家電であろうと　超精密半導体製造装置であろうと　、、、、

わたしには　すべて　アナロジーに見えております

AIを使ってソフト作成されている皆様

ソフトを資産化し　再利用可能なモデルとなるように、品質守れるように、、

AIへ指示できておられますか？

最大の問題は　アーキテクチャ　の要件を理解できていないことです

良いアーキテクチャは　良い性能を生みます

良いアーキテクチャは　良い品質を生みます

良いアーキテクチャは　良い効率を生みます

特にソフトウェア開発において、

　良いアーキテクチャ　は　一番ピンなのです

良いアーキテクチャなしに　無闇にAIにソフト生成させているとしたならば

どうやって　ブラックボックスで　品質保証するのでしょう？　

いくらAIに注文しても、ソフトウェア品質は高まらないことに気づくでしょう

一気に６０点のソフトウェアはAIでできてしまうのが曲者です

1つ直せば、2つ新しい問題が出る　

永遠なる答えのない　仕上げ試行錯誤地獄、でも品質は一向に上がらない

品質問題で　会社が　つぶれますよ

私のお客様は決してそうなっておりません、なりません

でも、、、日本全体の平均値は、

　　かなりヤバい会社が増えているような予感がしております

システム開発の　構想設計は　もっと　精度良くできる

　システム開発の　効率も品質も　もっと高めることができる！

　　私たちは　もっともっともっと　進化できる