私、学生の頃から、各種の制御技術について学んできて、色々試してきました。

Since I was a student, I have been learning about various control technologies and have tried many things.

大学で、ロボットの研究をやっていたからです。

I was researching robots at university.

現代制御理論、PID制御、ファジィ制御、などです（最近の制御のトレンドは知りません）。

Modern control theory, PID control, fuzzy control, etc. (I don't know about recent control trends).

実は、この「制御技術」というのは、「予測技術」と表裏一体の関係にあります。

This “control technology” is inextricably linked to “forecasting technology.

"未来"に起こるであろうふるまいを「予測」して、"今"その対策を打つのが「制御」です。

Control” is to ‘predict’ the behavior that will occur in the ‘future’ and take measures to deal with it ”now.

まあ、考えてみれば、制御とは「工学」の世界の話だけではなく、世の中のすべてのものが「予測と制御」の対象であるといっても過言ではありません。

Well, if you think about it, it is no exaggeration to say that control is not only about the world of “engineering” but everything in the world is subject to “prediction and control.

地震に対する避難対策、感染症の蔓延に対する防疫措置、財政対策、金融政策、少子化対策──これらはすべて「予測と制御」です。

Evacuation measures against earthquakes, quarantine measures against the spread of infectious diseases, fiscal measures, monetary policy, and birthrate reduction measures are all “forecasting and control.”

ただ、多くの場合、この「予測と制御」は上手く噛み合いません。一言で言えば、「難しい」。

However, in many cases, these “prediction and control” do not mesh well. In a word, it is difficult.

ロボットアームの制御も難しいですが、それでも機械の制御は、パラメータが有限数なので、時間をかけて力ずくでチューニングすれば良く、簡単に検証実験ができます。

Controlling a robot arm is also tricky, but even so, machine control has a finite number of parameters so that it can be tuned by force over time, and easily verified experiments can be performed.

比して、少子化対策は、パラメータの数が不明です。時定数も恐ろしく長い（10〜20年以上）。チューニングしようにも、どこに手を入れれば良いのか分からない上に、検証実験ができるわけでもありません。さらに糞面倒くさいことに、そのパラメータの一つに「人間」が入っている、ということです。

In contrast, the number of parameters for fertility reduction is unknown. The time constant is also terribly long (10-20 years or more). Even if you want to tune it, you don't know where to put your hands, and there is no way to conduct verification experiments. Even more annoying is that one of the parameters is “human.”

ところが、この超絶に難しい少子化対策のパラメータは、つまるところ2つだけです。「金」と「法律」です。

However, there are only two parameters for this strict fertility reduction policy: money and law. Money and law.

「金」は、試す方法が「たくさん」にできる、という効果があります。数を打てば当たることがあります。また「補助金」という形で、出産・育児を支援するという手段になりえます。

The “gold” has the effect of allowing “lots” of ways to try. If you hit a few, you may hit the right one. It can also be a means of supporting childbirth and childcare in the form of “subsidies.

「法律」とは命令です。仮説ですが、「結婚すれば納税（消費税を含む）を半分にする。出産すれば、さらに半分にする」という法律が成立すれば、かなり簡単に解決すると思います。

The “law” is an order. Hypothetically, if a law were passed that said, “If you get married, you pay half your taxes (including sales tax). If a law were passed that said, “If you marry, you pay half your taxes (including sales tax), and if you give birth, you pay half more,” it would be a fairly easy solution.

ただし、我が国の財政が成り立つかどうか分かりませんし、そもそもこれは「法の下の平等」という法治国家の理念を踏み躙る法律になります。

However, I do not know if our country's finances are viable, and in the first place, this would be a law that violates the principle of “equality before the law” and the rule of law.

（台湾で『独身税』の導入の真偽をめぐって、国会で大暴動が起きたことを思い出しています）

(I am reminded of the massive riot in the National Assembly over the authenticity of introducing the “bachelor tax” in Taiwan.)

予算案の審議で、「内容を精査する」と、野党議員がたびたび発言していますが、私はいまだかつて「精査した結果の報告書」なるものを一度も見たことがありません。

During deliberations on budget proposals, opposition party members often say that they will “scrutinize the contents,” but I have never seen a “report of the scrutiny results.

「金をかけて、場当たりでやってみる」というのが、現実解でしょう。

The real solution would be to “spend the money and try it ad hoc.”

もし、本当に「内容を精査する」なら、1年分の予算の審議に10年の時間が必要となることは、――制御（もやらされてきた）エンジニアとして、私が断言します。

If we really “scrutinize the content,” I can assure you that it would take 10 years to deliberate on a year's worth of budget - and as an engineer who has been in control (and has also been made to do so), I can assure you that it would take 10 years to do so.

「金をかける」というのは、「"当たり"を引く確率を高める」ということ以上の意味はありません。

Spending money” means nothing more than ”increasing the probability of winning.

ぶっちゃけ、私に関しては、少子化問題について「出生率を上げる」という"制御"については、諦めています。

As far as I am concerned, I have given up trying to “control” the declining birth rate.

むしろ、半分になった人口でサービス品質を落とさない、日本というプラットフォームの設計に力を注いだ方が、費用対効果は高いと信じています。

Instead, we believe it would be more cost-effective to focus on designing a platform for Japan that does not compromise service quality with a population cut in half.

先日、出張帰りの品川駅、横須賀線ホームへの入口の階段のところで、人が集っていました。

On my way home from a business trip the other day, people gathered at Shinagawa Station, at the entrance stairs to the Yokosuka Line platform.

何事かと思って覗いてみると、

I peeked in to see what was going on,

―― 階段に真っ逆さまになって、倒れている男性

"I looked over to see what was going on -- a man lying face down on the stairs."

倒れている男性の横には、吐瀉物と、その人のものと思われるスマホが落ちていました。

The man was lying on the ground, with vomit and a phone that appeared to belong to him on the ground next.

頭を下にして落ちている男性は、ピクリとも動かず、階段の真ん中で留まっていました。

The man falling with his head down did not twitch and stayed in the middle of the stairs.

体は全く動かず、声もなく、頭を下にして、俯せた状態のまま停止していました。

The man's body was completely motionless and without voice, and he had stopped, head down, in a prone position.

・・・えっと、この場合、何すればよかったんだっけ？

...Well, what was I supposed to do in this case?

と、私は、完全に思考停止してしまいました。

And I stopped thinking altogether.

そこに走り込んできた駅員さんのペア(男性と女性)がやってきたのを見て、ようやく我に返りました。

I finally came to my senses when I saw two station staff members (a man and a woman) come running in.

私は、その倒れている男性の横を通って、ホームに降りました。

I walked past the prone man and stepped down onto the platform.

-----

私、こういう状態の時になったら「救助支援をするように訓練されている」と思っていたのですが、それは思い違いだったようです。

I thought I was “trained to provide rescue assistance” in situations like this, but I was mistaken.

階段の真ん中で、真っ逆さまの状態で、意識不明のまま倒れて完全停止している人間は、はっきり言って「怖かった」。

The person falling unconscious and coming to a complete stop in the middle of a staircase headlong was “scary,” to say the least.

その男性を助ける手段が、1mmも思いつきませんでした。

I could not think of a single mm of means to help the man.

まず、どう動かせばいいのか。下手すれば階段を滑落していく可能性もありました。その男性はガタイが大きくて、仰向けにする方法のイメージもわきません。下手に動かして、状況を悪くするのではないかとも思っていました。

First of all, how could I move him? If I was not careful, I could slide down the stairs. The man was large, and I could not imagine turning him on his back. I also thought I might worsen the situation by moving him badly.

正直に言えば、「あ、もう、これダメだな(死んでいるな)」という感じでした(もちろん、これは主観であって、意識不明になっていただけだったかもしれませんが)

I was like, “Oh, my God, this is no good (He is dead).” (of course, this is subjective, and I may have just been unconscious).

駅員さんが、倒れている男性に何か話かけていたようですが、『意識なし！』という言葉が聞こえてきました。しばらくしたら、多くの駅員さんが男性の倒れた付近をブルーシートで、囲んでいました。

The station attendant was talking something to the collapsed man, and I heard the words, 'He is unconscious! After a while, many station staff members surrounded the area where the man had collapsed with blue sheets.

-----

私はふだんから、「他人のことは、ほっとけ」と言い続けています。

I have always said, “Leave other people alone.

今回の件で、自分は「救助支援を必要とする人」すらも「他人」として括っていたのだと気づかされました。まあ、それで自己嫌悪に陥るようなことは、特にありませんが。

This incident made me realize that I had been lumping even “people who need rescue assistance” as “others. Well, there is nothing in particular that makes me feel self-loathing.

「他人のことは、ほっとけ」とは、つまり「自分のことも、ほっとかれる」ということですから。

Because “leave others alone” means that “others will leave me alone," too.

私は、今の時代に必要なのは「積極的無関心」ではないかと思うのです ―― つまり、『人のことはほっとけ。自分のことだけやっとけ』です。

なるほど、なるほど、 ―― 「侍タイムスリッパー」を見た感想です。

Amazon Primeに、昨日から来ているのを見ました。

多分、ここから始まる地獄の半年の最後の休憩時間と考えて、部屋の暗くして、嫁さんと二人でリビングのテレビでソファーで観賞しました。

-----

今、宣伝用のページを見ているのですけど、『ああ、ここには書かれていないんだ』と分かりました。

私の記憶している限り、2回、驚かされるストーリー展開(転換)があります(ネタバレになるので書きませんが)。

自信をもって、お勧めできる映画です。

少なくとも、単なる「笑い」の映画ではなく、私には、本当に、真剣に、真面目に、『良い映画』でした。

fastapiによるプロセスのスレッド停止に関する原因究明のメモ

1. 問題の背景と経緯

1.1. 問題の内容

1. fastapiからC言語で作成したプログラムを起動すると、Cプログラムの中にあるスレッドが途中で停止するという問題が発生している。

2. Cプログラム をfastapiプログラムから起動したの場合、udpマルチキャストの受信を⾏うスレッドが、数回〜10数回⽬で停⽌することが発覚。

1.2. 事前確認事項

1. fastapiプログラムから Cプログラムを起動せず、コマンド(手入力)で起動した場合、この問題は発⽣しないことは確認済。

2. また、1のCプログラム起動だけでなく、複数のCプログラムを起動した場合においても、この問題が発生しないことも確認済み。

3. 以上より、この問題は、Cプログラム本体ではなくて、それを起動するfastapi(fastapiプログラム)側に問題があると推認された。

4. この問題は、以下のfastapiプログラムのコードの差し替えによって解決することが判明している。

問題が発生するケースでのfastapiプログラムのコマンド発生プロセスのコード

(1)
pid = await run_command_and_get_pid(command)

(2)
task = asyncio.create_task(run_command_async(command))
process = await task
pid = process.pid

# なお、上記(1)(2)は、実質的には同じ処理である

問題が発生しないケースでのfastapiプログラムのコマンド発生プロセスのコード

with open(os.devnull, 'w') as devnull:
process = subprocess.Popen(shlex.split(command), stdout=devnull,
stderr=devnull)
pid = process.pid

2. 問題点の差分の明確化

この問題の発生/不発生は、以下の2点に集約できることが確認された。

1. asyncio.create_task と await を併用した非同期処理
2. 上記を使用しない、subprocess.Popen を使用したプロセス処理

3. fastapiプログラムの制御対象である、Cプログラムの特徴

Cプログラムは、映像転送を行うメインルーチンと、SRT転送の状況を常時把握するスレッド、自分と自分以外のCプログラムのプロセスをリアルタイムでカウントするスレッドと、稼動中のCプログラムに通信を行うためのスレッド(現在未使用)からなる、映像転送&プロトコル変換プログラムである。

1Mbps以上の映像転送を行いながら、映像転送環境を常に把握し続ける必要のある、リアルタイム性能が要求される高負荷の制御プログラムである。

4. 検討

問題の原因を分析するためには、いくつかの可能性を考慮する必要がある。特に、asyncio.create_task や await を使用した非同期処理と、subprocess.Popen を使用したプロセス管理の違いが影響している可能性がある。この点を中心に考察する。

4.1. asyncio.create_task や await を使用した非同期処理において、排除できる可能性

4.1.1. 非同期処理の影響の可能性

asyncio.create_task と await を使用した場合、非同期処理によってプロセスの状態が意図しない形で処理されている可能性があるが、今回はこれには該当していない。プロセス自体が稼動していることは確認している。したがって、Python のガベージコレクションやスケジューリングの問題によって、起動したプロセスが適切に管理されないケースは考慮しなくてよい。

4.1.2. タスクが解放された可能性

ログファイルを用いて確認した結果、asyncio.create_task を使用して作成されたタスクが適切に監視されず終了した形跡はないので、この件について考慮しなくてよい。

4.1.3. await によるブロックの影響の可能性

非同期関数内で await を使用してプロセスの終了を待っていると、FastAPI のリクエストが別の処理と競合し、プロセスの動作に影響を与える可能性はあるが、今回はCプログラムが1個の場合でも発生しているので、これも考慮する必要はない。

4.2. asyncio.create_task や await を使用した非同期処理において、排除できない可能性

4.2.1. イベントループのスケジューリングとリソースの競合

asyncio を使用すると、イベントループによってすべての非同期タスクがスケジュールされる。しかし、他のタスクやリクエスト処理が増えると、イベントループ全体の負荷が高まり、処理が遅延する可能性がある。

つまり、fastapiプログラムが、Cプログラムを含めた全体のタスク管理を行うため、Cプログラムの自由な実行が制限されるという問題が発生しうる。

この状況では、特定のタスク（今回の場合はsend_bitrate_or_count_processes のスレッド）への割り当てが遅れることで、スレッドが停止したかのような挙動が発生することがありえる。

4.2.2. プロセス管理の不安定さ

非同期タスクでは、プロセス管理がイベントループの中で行われるため、イベントループ自体の負荷やスケジュールの影響を受けやすくなる。

つまり、リアルタイム性の高い高タスクのCプログラムの実行が、fastapiプログラムの動作を遅らせ、その結果、fastapiプログラムの管理下にあるCプログラムの実行が制限されるという悪循環を発生させると考えうる。

4.2.3. プロセスのモニタリングの不安定さ

非同期処理では、プロセスの監視 (monitor_process_status) を含むさまざまなタスクが並行して実行される。この際、イベントループがプロセスの管理や状態確認の処理を後回しにすることで、プロセスの実行状態が適切に反映されず、スレッドが停止しているかのような挙動になったと考えうる。

4.3. subprocess.PopenによってCプログラムのスレッド問題が解決した理由理由

4.3.1. subprocess.Popen との違い

subprocess.Popen を使用して起動する場合は、Python の非同期処理機構に依存されることなく(fastapiプログラムの管理に組込まれないため)、独立してプロセスが管理される。このため、プロセスの状態が安定して保たれたと考える。

これは事実上、手入力でコマンドを押下する処理と同じことをやっており、前述の「コマンド(手入力)で起動した場合、この問題は発生しないことが確認済」という内容と整合が取れている。

5. 結論

今回のプログラムにおける問題の原因は、非同期タスクがイベントループのスケジューリングに依存している点に起因していると考えられる。

具体的には、非同期処理 (asyncio.create_task + await) のリソース競合やスケジューリングのタイミングによって、プロセスの管理や監視が適切に行われず、スレッドが途中で停止しているように見えたと考えられる。

以上より、subprocess.Popenの利用によってCプログラムのスレッド問題が解決したことは、合理的に説明ができる。

以上

6. 付録

6.1. 「非同期タスクでのコマンド実行 (asyncio.create_task + await)」の意義（なんのために、このような仕組みが用意されているのか）

非同期タスク (asyncio.create_task + await) の意義は、主に以下の3つの観点に集約される

6.1.1. 高いスループットと効率的なリソース使用

非同期タスクは、待機中のリソース（たとえば、ネットワークI/OやファイルI/Oなど）を効率的に使用しながら、他のタスクの実行を並行して進めることを可能にする。これにより、CPUの使用率を高め、多くのリクエストやタスクを同時に処理することができる。例えば、クライアントからのHTTPリクエストに対する応答待ちの間に、他のタスクの処理を進めることができるため、高いスループットが実現される

6.1.2. ブロッキングの回避とレスポンスの向上

従来の同期的な実装では、一つの処理が完了するまで他の処理を待たせる必要がある（ブロッキング）。これに対して、非同期処理では、あるタスクがI/O待機などで停止している間にも、他のタスクが進行するため、アプリケーション全体のレスポンスが向上する。具体的には、ネットワークのレスポンスを待っている間に他の処理を進行させることで、CPUのアイドル時間を減らし、待機時間のロスを最小化する。

6.1.3. 大量の同時接続やリクエストの処理に強い

非同期タスクの仕組みは、大量の接続やリクエストを効率的に処理するために設計されている。特に、Webアプリケーションやマイクロサービスでは、多くのクライアントからの接続を管理し、レスポンスを返す必要がある。例えば、FastAPI などの非同期対応Webフレームワークでは、同時に多数のリクエストを処理し、レスポンスを返すことが求められる。このとき、asyncio.create_task と await を利用することで、各リクエストを非同期タスクとして並列に処理できる。

6.2. Cプログラムは、映像転送（中継）とプロトコル変換を行う典型的な制御プログラムで、リアルタイムのパフォーマンスが要求されるプログラムである。このようなプログラムの起動にfastapiを用いるのは正しい選択だったか？

FastAPIを使用してリアルタイムパフォーマンスが要求される制御プログラム（Cプログラム）を起動することは、設計上の選択としていくつかの利点と課題が存在すると考えた。

6.2.1. FastAPIを使用する利点

6.2.1.1. 軽量で高速な非同期フレームワーク:

FastAPIはPythonの非同期処理を活かして、高速かつ効率的にリクエストを処理できる。これにより、複数のリクエストを並列に処理することが可能であり、APIベースのコントロールが求められる場面では有効である。

6.2.1.2. シンプルで明快なAPI構築:

RESTful APIを簡単に構築できるため、外部からのコントロールやモニタリングが要求される制御プログラムにとっては適切である。また、外部から簡単にステータス確認やプロセスの制御が可能になる

6.2.1.3. スケーラビリティの確保:

FastAPIは、UvicornやGunicornといったASGIサーバーと組み合わせることで、スケーラブルな構成をとることができる。リクエストの多い状況や複数の制御要求が同時に発生するような環境で柔軟に対応できる。

6.2.2. FastAPIを制御プログラムに用いる際の課題と考慮点

一方で、リアルタイムのパフォーマンスを要求される制御プログラムにおいて、FastAPIの非同期タスクやイベントループの特性が以下のような問題を引き起こす可能性がある。

6.2.2.1. イベントループの負荷と競合:

FastAPIは非同期フレームワークであるため、複数のタスクが同時に実行されることを前提としている。しかし、リアルタイム制御を要するプログラム（映像転送やプロトコル変換など）の場合、イベントループの負荷が高まると、タスクの遅延やリソース競合が発生しやすくなる。

6.2.2.2. リアルタイム性能の不安定さ:

映像の中継やプロトコル変換を行うプログラムでは、タイミングやデータ転送の精度が重要である。FastAPIを介したプロセスの管理やコマンドの実行は、イベントループに依存するため、Pythonのインタープリタの遅延やスレッド管理の問題がリアルタイム性能を損なうリスクがある。

6.3. (付録の)結論

プロセスの制御や起動部分をFastAPIから分離する本件の方式は、fastapi + 制御プログラム の併用方式としては最適である、と考える。

昔、「100W電球」というのが普通に使われていました。

In the past, “100W bulbs” were commonly used.

今は、ほとんどLED電球に替わって、同じ程度の光量に対して、消費電力はざっくり1/5程度(20W)程度です。

Most of them have been replaced by LED bulbs, which consume roughly 1/5 of the power (20W) for the same amount of light.

比して、ラズパイ(Raspberry Pi 4 Model B)の消費電力は、5.5～7Wくらいです。

In comparison, the power consumption of Raspberry Pi (Raspberry Pi 4 Model B) is about 5.5 to 7W.

-----

先日の出張で、工場の実験システムで、このラズパイ1台で、4つのリアルタイム映像の転送ができることを確認してきました。

On a recent business trip, I confirmed that a single Raspi can transfer four real-time video images in an experimental system at a factory.

また、ラズパイを使って2万人が同時に動くマルチエージェントシミュレータのデータベースを動かしています。

We also use Raspi to run a multi-agent simulator database with 20,000 people running simultaneously.

コストパフォーマンスから鑑みて、

Given cost performance,

―― コンピュータ(というか半導体)って、凄いなぁ

"Computers (or semiconductors) are awesome!"

と実感しています。

I realize that this is not the case.

------

以前、この抜群のコストパフォーマンスであるはずのコンピュータの消費電力が、生成AIによって「爆上がりする将来」の話をしました。

I have previously talked about a future in which the power consumption of computers, which are supposed to be outstandingly cost-effective, will “explode” due to generative AI.

―― 生成AIの登場が、これまでの私の仮説を、次から次へとひっくり返しに来ているなぁ

生成AIが使用する電力が、いかに凄まじいものであるかが、分かろうというものです。

This is a good indication of the tremendous amount of electricity used by generative AI.

-----

などと考えていて、ふと気がついたのですが、

I was thinking about this, and it occurred to me that,

―― もしかしたら人間の知的能力(ChatGPTに相当する能力)というのも、電力量の単位で置き換えられるかもしれない

"Perhaps human intellectual capacity (equivalent to ChatGPT) could also be replaced by units of electricity."

電力の単位は、カロリーの単位に、置き換え可能です。

Units of calories can replace units of electric power.

例えば、

For example,

100W の電力を1時間（3600秒）使用した場合のカロリー量は、

The amount of calories for one hour (3600 seconds) of 100 W of power is the following.

$$E_{\text{cal}} = \frac{100 \times 3600}{4.184} \approx 860,420 \text{ cal}$$

これは、ざっくり、860 kcal は 約1時間半のランニング（10 km/h） や 約3時間のウォーキング（5 km/h） に相当します。これは、一般的な成人が1日に消費するカロリーの約1/3～1/2に匹敵する運動量です。

Roughly, 860 kcal is equivalent to about 1.5 hours of running (10 km/h) or 3 hours of walking (5 km/h). This is equivalent to about 1/3 to 1/2 of the calories a typical adult burns daily.

と、ここまでは、よく使われてきた「運動量とカロリーと体重の関係」を説明する話です。

So far, we have discussed the commonly used “relationship between physical activity, calories, and body weight.”

-----

しかし、ここからが違う。

But here's the difference.

これからは、ChatGPTの作ったレポート(とその電力量)、私が作ったレポートを教授とか上司が比較して、数値でジャッジする時代がくる。

The time will come when the reports made by ChatGPT (and their power) and my reports will be compared by professors or supervisors and judged by the numbers.

『うん、江端のこのレポートは、"10ワット"くらいだな』

"Yeah, this Ebata's report is likely to “10 watts."

という世界の出現です。

Such is the emergence of the world.

嫌な世界です。

It is a disgusting world.

そして、この世界の最も嫌なところは、「頭脳を使っている人は、エネルギー消費が激しい」という考え方から派生する、「太っている人間は、頭を使っていない」という間違った認識への誘導、がありえるということです。

The most disgusting part of this world is that there can be an induction, derived from the idea that “people who use their brains use more energy,” into the false perception that “fat people don't use their brains.”

いや、正確にいうと、私は、これが「間違っている」という論理的根拠を持っている訳でありません。もしかしたら『科学的に正しい』という可能性も否定できません。

No, to be precise, I do not have any logical basis for saying this is 'wrong.' I cannot deny the possibility that it may be 'scientifically correct.'

あんまり考えたことはなかったのですが、今考えてみると、テレビに出てくる科学者や経営者や、ノーベル賞の受賞式などに登場する人物で『この人、すごく太っているなぁ』と思った人の記憶がありません。

I never really thought about it, but now that I think about it, I can't remember any scientist or businessman on TV or at Nobel Prize ceremonies who thought, 'This person is so fat.

-----

ともあれ、私は、今の段階で、誰かが「知的運動量と体重」の関係を言い出す可能性について、警告を出しておきたいと思います。

Anyway, at this stage, I would like to warn you about the possibility of someone saying there is a relationship between “intelligent physical activity and weight.”

「ただの運動量と体重」で止めておきましょう。それ以上やっても、誰も幸せになりませんから。

Let's stop at “just physical activity and weight.” No one will be happy if you go any further than that.

自分の頭脳の運動量まで定量化されては、人生、やってられません。

I can't live my life if I have to quantify the amount of exercise my brain does.

-----

ただ、私の場合、論文執筆の後とか、ハードなプログラミングの直後とかには、確かに体重落ちているんですよ。

But in my case, I certainly lose weight after writing a paper or right after complex programming.

酷い時には2kgぐらい減っていて、ゾッとすることがあります。

In the worst cases, I have lost about 2 kg, which can be horrifying.

あと、メンタル面がやられている時も、体重落ちます。こっちは、もうびっくりするほどの勢いで痩せていきます。

Also, I lose weight when my mental health is hit. I lose weight at an alarming rate.

-----

最近、2つのプロジェクトのプログラムの問題点が解決しました。

Recently, I have resolved program issues with two of my projects.

1つは、半年くらい悩んでいたバグだったので、これを見つけた時は、本当にホッとしました。

One was a bug I had been struggling with for about six months, so I was relieved when I found this.

もう一つは、前述の「4つのリアルタイム映像の転送を確認」です。

The other is those above “confirm four real-time video transfers.

今の私は、(人間ドッグ時の基準体重より)2kg太っています。

I am now 2 kg overweight (from the standard weight at the time of the physical exam).

「その着せ替え人形は恋をする」を読了して、コスプレという文化と技術とコスプレに傾倒する人たちの熱意とかを知ることができました。このようにコミックによって、サブカルそのものを理解できなくても、サブカルを『分かったような気にはなれる』と思いました。
サブカルに限らず、このような表現文化に関するマンガ、その他のメディアについて、ピックアックして頂き、その文化と技術と傾倒する人たちの熱意について、一覧で纒めて頂きたいです。

承知しました。以下に、先ほどの表現文化系に加えて「スポーツ」を描いたマンガを含めた一覧をアップデートしました。野球・サッカーはそれぞれ1作品のみに絞り、あまり知られていない競技（相撲・アーチェリー・スケートなど）を中心にピックアップしています。

---

表現文化・スポーツを描いたマンガ・メディア一覧

（文化・技術・情熱に注目）

---

ご覧のとおり、スポーツといっても「競技」だけでなく、「表現」や「精神性」が求められるものが多く、文化と地続きです。相撲や弓道、薙刀のような日本伝統の身体文化にも熱い想いが描かれています。

今回の私の質問の意図は、「サブカルであれマイナーなスポーツであれ、それを知ろうという行動を起こすことなく、批判しているヤツは『バカ』と断言して良い」、ということです。

VSCodeでC言語のインデントをGo言語のようにTABキーで自動的に整える方法を説明します。

1. C/C++拡張機能をインストール

まず、MicrosoftのC/C++拡張機能がインストールされているか確認してください。

• VSCodeの「拡張機能」 (Ctrl+Shift+X) で「C/C++」を検索
• ms-vscode.cpptools をインストール

2. settings.json を作成

.vscode フォルダの中に settings.json を作成します。

方法1: VSCodeのGUIを使う

1. .vscode フォルダ内で 右クリック → 新しいファイル
2. ファイル名を settings.json にする


3. settings.json に設定を追加

作成した settings.json を開いて、以下の内容を記述します。

{
  "editor.formatOnType": true,  // セミコロンや波括弧入力時に自動フォーマット
  "editor.formatOnSave": true,  // 保存時に自動フォーマット
  "editor.tabSize": 4,          // タブ幅を4に設定
  "editor.insertSpaces": false,  // タブをスペースに変換しない
  "C_Cpp.clang_format_fallbackStyle": "Google", 
  "C_Cpp.clang_format_style": "{ BasedOnStyle: Google, IndentWidth: 4, UseTab: Always }"
}

4. Emacsキーバインドを使いつつTABの動作を変更

Emacsのキーバインドを保持したままTABの動作だけ修正したい場合、keybindings.json でTABキーの挙動を変更できます。

設定方法

1. Ctrl+Shift+P で 「Preferences: Open Keyboard Shortcuts (JSON)」 を検索
2. keybindings.json を開く
3. 以下の設定を追加：

   [
     {
       "key": "tab",
       "command": "editor.action.reindentlines",
       "when": "editorTextFocus"
     }
   ]
   
   

   これで、私の環境の方では何とか動いたようです。
   

[.vscode/c_cpp_properties.json]

{
	"configurations": [
		{
			"name": "Win32",
			"includePath": [
				"${workspaceFolder}/**",
				"C:/msys64/mingw64/include"
			],
			"defines": [
				"_DEBUG",
				"UNICODE",
				"_UNICODE"
			],
			"windowsSdkVersion": "10.0.22621.0",
			"compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
			"cStandard": "c17",
			"cppStandard": "c++17",
			"intelliSenseMode": "windows-gcc-x64"
		}
	],
	"version": 4
}

[.vscode/launch.json]

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cデバッグ (MinGW64)",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "gdb を有効化",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe"
        }
    ]
}

[.vscode/settings.json]

{
	"editor.formatOnType": true, // セミコロンや波括弧入力時に自動フォーマット
	"editor.formatOnSave": true, // 保存時に自動フォーマット
	"editor.tabSize": 4, // タブ幅を4に設定
	"editor.insertSpaces": false, // タブをスペースに変換しない
	"C_Cpp.clang_format_fallbackStyle": "Google",
	"C_Cpp.clang_format_style": "{ BasedOnStyle: Google, IndentWidth: 4, UseTab: Always }"
}

[.vscode/tasks.json]

{
	"version": "2.0.0",
	"tasks": [
		{
			"label": "Cコンパイル (MinGW64)",
			"type": "shell",
			"command": "C:/msys64/mingw64/bin/gcc",
			"args": [
				"-g",
				"${file}",
				"-o",
				"${fileDirname}/${fileBasenameNoExtension}.exe"
			],
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"problemMatcher": [
				"$gcc"
			],
			"detail": "MSYS2 MinGW64 の GCC を使用して C をコンパイル"
		}
	]
}

作成したCファイルをアクティブにし、Ctrl + Shift + B を押してビルドタスクを実行したあと、vscodeのデバッグができるようです。

私は『都市は"雪"に弱い』ということを、思い知っています。

I have learned that cities are vulnerable to snow.

今朝も思い知りました。

I was reminded of this again this morning.

雪の日が出張日(だいたい隔週)に当たるとは、とても残念です。本当に私は運が悪い。

I'm sorry that snow days fall on your business trip days (usually every other week). I'm unlucky.

今日も、積雪もしていない少量の雪の影響で、品川までの電車のダイヤの、ほぼ全部が遅延していました。

Today, almost all of the train schedules to Shinagawa were delayed due to a small amount of snow that had not accumulated.

それでも、なんとか、目的の特急列車に乗り込むことができて、安堵しています。

Still, I am relieved that I boarded the express train I wanted.

-----

都市は"雪"だけでなく、"風"にも弱いです(出張が中止になったことがあります)。"雨"にも弱いです。"地震"に弱いことは、世界共通だとは思いますが。

Cities are vulnerable not only to “snow” but also to “wind” (I once had to cancel a business trip).” They are also vulnerable to “rain.” Earthquakes” are common in the world, I think.

思うに、自然災害の影響を受けにくい場所が、都市になりやすかったのだろうと、と思います。

I think places less susceptible to natural disasters were more likely to become cities.

日本の都市の多くは、(1)起伏の少なく、(2)河川があり、(3)湾岸に直結しています。これらは、人流や物流を支える要素です。

Most Japanese cities have (1) few ups and downs, (2) rivers, and (3) direct connections to the Gulf Coast. These are elements that support logistics for human flow.

しかし、重要なことを忘れてはなりません。

However, we must not forget something important.

都市を成立させている土地は、「氾濫(水害)がくりかえされることによって、土砂によって平地が広げられたもの」です。

The land on which cities are built is “the flat land that has been expanded by sediment due to repeated inundation (flooding).

すなわち、氾濫(水害)が、都市を作ってきた、と言えます。

In other words, it can be said that flooding (flood damage) has created cities.

調べてみて頂ければ分かりますが、日本の大半の都市の水害ハザードマップは、だいたい「真っ赤」です。

As you can see, flood hazard maps for most Japanese cities are usually “bright red.

しかし、真っ赤なエリアは、生活をしていく上ではとても便利です。起伏が少なく、繁華街へのアクセスが良い。道路も、公共交通も充実しています。なにより人口が多い。

However, the bright red area is a great place to live. There are few ups and downs and easy access to downtown. There are good roads and public transportation. Above all, the population is large.

人口が多いと税収が多くなり、税収が多くなれば、福祉施設(図書館などを含む)を建設するコストも捻出でき、文化的レベルの高い街になります。

A larger population means more tax revenue, which can be used to defray the cost of building welfare facilities (including libraries, etc.) and give the city a higher cultural level.

-----

そんな風に考えていくと、日本列島というのは、実に面倒くさい国土ですよね。

When you think about it in this way, the Japanese archipelago is a troublesome land.

■山間部は豪雪で孤立しかねないし、

■Mountainous areas could be isolated due to heavy snowfall,

■沿岸部は津波の恐怖に怯えなければならず、

■Coastal areas have to be frightened of tsunamis,

■そのどちらでもない地域は、公共交通が少なくて、外出しにくい。

■ Areas that are neither of these have little public transportation and are difficult to get out and about.

そして、

And,

■それらのいずれでもない都市部の大部分は、水害レッドエリアで、大地震の場合、水、電気、ガスのインフラが破壊され、物流が途絶やすく、命の危険に直結している

■Most of the urban areas that are not one of these are flood-red areas, where a major earthquake could destroy water, electricity, and gas infrastructure, easily disrupt logistics, and directly endanger lives.

加えて、

In addition,

■比較的アクセスの良い沿岸部の多くには、原発等の発電所が建設されている

■Nuclear power plants and other power generation plants are being built in many relatively accessible coastal areas

さらに言えば、

Even more so,

■日本列島には『活断層がない』という場所がありません。そして、実際、毎日100を越える地震が発生しています(体感できないだけです)。

■There is no place in the Japanese archipelago is “free of active faults. And in fact, over 100 earthquakes occur every day (you can't feel them).

毎日100～200の地震が発生しているのですから、「大地震が起きませんように(もし起きるなら、私の関係のない場所でヨロシク)」と祈っても、多分、無駄でしょう。

南海トラフ地震は、これまで、90～150年周期で、発生してきました。今後、30年以内の発生率は、80%だそうですが、私のような地震学の素人でも、納得できる数値だと思います。

Nankai Trough earthquakes occur over a 90- —to 150-year cycle. The probability of occurrence within the next 30 years is said to be 80%, a figure that even an amateur seismologist such as myself can agree with.

私だけが『ディスプレイが突き刺さった状態の遺体で発見される』

-----

外国の人から、

From a foreigner,

―― なんで、そんなに危険な日本列島なんかに住んでいるの？

"-- Why do you live in such a dangerous Japanese archipelago?"

と問われたら、合理的な説明ができないです。

I cannot give a rational explanation.

これについては、以前にお話をしましたが、『自分の生活居住区に対するこだわり』は、論理的には説明できないのです。

I have discussed this before, but 'commitment to one's living quarters' cannot be explained logically.

まあ、それでも理屈を捻り出すとしたら、"SIL"を持ち出すしかないかなぁ、と思っています。

If I had to develop a theory, I would have to bring up “SIL.”

SILって何だろう

SILを主観的に説明すれば、『自分が生きている間に、死に直結する自然災害が発生しないことを、祈ること』ということでしょう。

A subjective explanation of SIL would be 'to pray that a natural disaster that directly leads to death will not occur in one's lifetime.

私は、政治団体「NHKから国民を守る党」(N国)の党首へのテロ事件の犯人を非難します。

I condemn the perpetrators of the terrorist attack on the leader of the political group “Party to Protect the People from NHK” (N-Kokoku).

嘔吐主義(ゲロリズム)を主導した人物が、『マスコミがこの事件を一向に報道しない』だの『国民からの同情やテロに対する批判がない』だのと言っていたとしても、『一体、どの口が・・・』などと言ってはならないのです。

If the person who led the vomits (Gerolism) says that 'the media never reports this incident' or 'there is no sympathy or criticism of terrorism from the public,' we should not say, 'What the hell are you talking about...?

私は、これを、"テロリズム(暴力主義)"ではなく、"ゲロリズム(嘔吐主義)"と命名したいと思います。

いかなる人物であろうとも、テロリズム(暴力主義)は否定されなければならないのです。

Terrorism must be rejected, no matter who it the target.

たとえ、

Even if,

■脅迫罪および威力業務妨害罪で東京地裁から懲役2年6カ月、執行猶予4年の有罪判決を受けていようが、

He may have been convicted of intimidation and obstruction of business with force by the Tokyo District Court and sentenced to two years and six months in prison with a four-year suspended sentence,

​■兵庫県議会の竹内英明元県議の死去に際し、SNSで虚偽の情報を発信したとして、死者に対する名誉毀損罪が成立する可能性があろうが、

On the occasion of the death of Hideaki Takeuchi, a former prefectural assembly member of the Hyogo Prefectural Assembly, he may be charged with defamation of character against the deceased for sending out false information on a social networking service,

■そのくせ、「反社会的カルト集団」と言われたことに対して、名誉毀損訴訟を起した結果、請求棄却されていようとも、

He filed a defamation lawsuit against what he called an “antisocial cult group,” even though the claim was dismissed as a result,

『奴は不快だ』という理由だけで、テロをしかけていたら、世の中テロだらけになってしまいます。

If we were to start terrorism just because 'he is an offensive person,' the world would be whole of terrorism.

-----

これを認容すると、私(江端)も、簡単にテロの対象になってしまう世の中が、普通になってしまいます。

If we allow this to happen, it will become the norm in a world where I (Ebata) can quickly become a target of terrorism.

それは、困るんですよ ―― まあ、私はゲロリストではありませんが。

That's the trouble -- however, I am not a vomitist.

SILって何だろう

---

本ページは、 SILに関するコラム(その1) と、 SILに関するコラム(その2) に対してのご批判と、その後のご指導を頂いた、 「真っ赤なレモン @_red_lemon 」さん から頂いたSILに関する有益なご意見を、 可能な限り変更を加えず、掲載したものです。

今回、このような形で、「真っ赤なレモン @_red_lemon 」さんのご意見を 掲載させて頂くに至ったのは、

 

• 「真っ赤なレモン @_red_lemon 」さん のSILのご解説が、恐しく分かりやすいこと
• SILに関する基本的な概念を説明する書籍が、現時点において絶無であること
• 今後の製造業のグローバル対応を考えた時、このご解説の内容は、技術者の皆さんにとって、素晴しく役に立つであろうこと

という理由に因ります。

この度、「真っ赤なレモン @_red_lemon 」さん のご許諾を頂き、この文章を公開 させて頂くことにしました。

なお、本文に関する文責は、全て、この文章を編集した江端智一に帰するものと致します。

2012年11月11日(日) 江端智一

 

• E-mailはこちら(スパム対策)
• 江端さんへ電子メールを出す前に(2001年より施行)

---

Q SILってなんですか？

 

A SILとは、機械の信頼性に関する指標で、平均故障間隔（MTBF：Mean Time Between Failures）という考え方を使います。

簡単に言うと、

「昨日クーラーが壊れたので、今修理してもらった。次はいつ故障しそう？」

「そうだねえ、大体5年後かなぁ」

と言えば、この場合のMTBFは、5年＝43800時間 となります。

SILとは、このMTBFで、その装置やシステムの信頼性を示す指標です。ざっくりこんな感じです。

・SIL0：MTBFが10年未満

・SIL1：MTBFが10年以上～100年未満

・SIL2：MTBFが100年以上～1000年未満

・SIL3：MTBFが1000年以上～1万年未満

・SIL4：MTBFが1万年以上～10万年未満

まず、SIL0（シルゼロ）、SIL1（シルワン）、SIL2（シルツー）……という分け方をしているのは、昼定食を「人件費と材料費が1647円の定食」というのを、単に「梅定食」と呼んでいるのと同じことで、単にこうしたほうが、理解と管理がラクというだけのことです。

 

Q SIL1やSIL2というのは分かります。SIL3,SIL4などというものがあるのは何故 ですか。これは、巨大事故発生時の被害者数の期待値と考えれば良いのですか。

 

A SILは製品の期待値がSIL2になるようにするための道具だ、と言ってよいです。

江端さんがコラムで書いている、

>「SIL2の私（原発、電車、旅客機）は、あんたの人生において、1度だけは、あんたを殺すかもしれないよ」ということです。

も、

>つまり、「人を殺すことを前提とした安全」の概念が含まれていると考えれば、SILを理解できるわけです。

も、全くそのとおりです。大局としては間違っていません。

では、私が気になったのはどこか。次の部分です。

>SIL3（MTBF：1000年～1万年未満）やSIL4（MTBF：1万年～10万年）がなぜ必要なのだろう？　という疑問が残ります。その答えは「期待値」です。

この考え方の筋道は、的外れです。

SIL3やSIL4が必要な理由は、次の考え方からです。

 

---

「壊れない」製品を作ることは、できない。（←ここはあきらめている）

そこはあきらめないと、話が先に進まない。

現実を見て物事を前に進められる我々工学の世界の住人は、 理屈にこだわって何もできない人たちよりも、ずっとマシ！

では、どれくらいの頻度の故障だったら、世間は納得してくれるだろうか？

---

↓

---

まあ、製品のSILがSIL2だったら、世間は納得してくれるんじゃね？

受容されるんじゃね？

（これは、まさにALARA。納得できるかどうかを厳密に突き詰めることはできない。 　人それぞれの価値観の相違があるため、泥沼になる）

---

↓

---

それはともかく、最近は部品の集積度が上がった。

「部品の集積度が高い製品」ほど、壊れる確率は高くなっちゃうよね。 どの部品が壊れるか分からないし、製品を使って100年もかかる試験が できるわけないよね。

---

↓

---

部品単体なら、加速試験ができるんじゃね？

それに、部品単体のMTBFをすごーく長くしておけば、 製品での試験をしなくてもいいじゃん！

「そ、それだ！」

---

↓

---

部品単体のMTBFをどれくらいにすれば、製品の試験をしなくてすむんだろう？

自動車の部品が、約1万個。そのうち、壊れたら安全性に関わる部品は 100個くらい。この100個が壊れなければ安全性には問題ない。

他の部品が壊れても、保証修理でタダで修理すれば済む話だし。

とすると・・・この100個の部品をSIL4（MTBF：1万年～10万年）に できれば、自動車じたいは、ざっと計算してSIL2（MTBF：100年～1000年）だ！

---

↓

---

というワケで、部品メーカーのみなさん。SIL4の部品を我が社に納入してください。

---

↓

---

部品メーカー「ええ～～！」

---

どんどんグダグダになっていきましたが、これが真相です。

部品の段階でのSILをSIL4まで上げておくと、 ほとんどの製品（全部品が約1万個、そのうち安全に関わる部品が約100個の製品）で、 ほぼSIL2が達成できます。そのために、SIL4が必要。

安全に関わる部品がもっと少ない場合は、SIL3で足ります。

製品メーカーは、部品代に高いお金を払うかもしれませんが、ラクをします。

なお、SILをいう考え方を自動車業界が強く推進している背景には、 電子部品が自動車に多数使用されるようになった、ということがあります。

電子部品は、機械に比べて部品の集積度が非常に高い。

それまでは自動車の部品を「できるだけ細かいレベルに分けて」数えても、 1万個程度でしたが、電子部品が使われるようになった途端に2～3万個に増えました。 （抵抗1個でもバラして4個と数えるような、極端な数え方ですけれど。）

SILは、「部品の集積度が高い製品」を前提とした考え方から生まれています。

 

Q SILがあって嬉しいことって何ですか？

 

A リスクを抽出し（想定し）、その個々のリスクレベルを全て「社会的に受容できる程度まで低減する」ことです。

これはISOに規定されていることです。

ISOの制定は欧州が主導しており、欧州の考え方の根底には「モノは壊れる。 人は間違える」があります。だから、考え方は「故障をゼロにする」のではな く、「モノは壊れる。人は間違える。それで発生するリスクを含めて、受容で きるレベルまでリスクを低減する。受容できるレベルまで低減されたリスクは、 社会が受け入れるべき」となり、現実的に安全性を確保していこうとしていま す。

つまりは、「社会に受容してもらう」＝「人々に納得してもらう。納得させる」 ことも、メーカーにとっては重要になります。

どうやって人々に納得してもらうか。

モノをベースに、客観的な理解を得ようとする取り組みが、SILのような考え 方を導入する動機の一部分としてあります。

通常のメーカーはそうやって、なんとかお客さまや社会に納得してもらえるよ うに努力をしています。

しかし、この考え方には弱点もありました。

例えば、原発の場合、モノを変えずに人を納得させようとしました。

「中長時間の全電源喪失を考えなくて良い理由を作文して下さい」などといった、 モノや実態を見ずに口先だけで人を納得させようとする姑息なやり口をしました。

そして、作文能力の高い人が多かったのでしょう。 優秀な作文がたくさんできたでしょう。

人々は納得させられてしまいました。モノは何も変わっていないのに。 [事故が発生する頻度]は非常に低いものの、ゼロではありません。 それを、ゼロだと思わせ、想定外ということにしました。

 

Q SILが基準としている「物差し」は何ですか。

 

A 人命です。

「SILで想定している『故障』とは、人命に関わるような故障のみを指している」 ということは、知っておかなければなりません。

極端に言うと、

「『安全に停止できるような故障』なら、1年に何回起こってもかまわない」

ということです。

（もちろん、お客さまからクレームが来ないようにしなければなりませんので、 　『安全に停止できるような故障』も減らそうとはします。）

 

Q 「SIL4」と言葉で言うのは簡単ですが、1万年以上故障しない部品なんて、 一体、どうやって実現するのですか？

 

A 基本的には電子部品のSIL4などは部品の多重化で達成します。

大雑把に書くと

Aという部品をSIL4にするためには Aの機能を達成する部品を作ります。aとします。

aを試験すると、SIL2でした。

（aの試験は、実際に時間をかけたり、加速試験をしたり、様々な方法で調べます。） aを2個（a1とa2と呼ぶ）、論理的に並列に(or回路、でしたっけ？）組み合わせて、 部品Aとします。

Aはa1とa2の両方が壊れないかぎり正常に機能しますので、

SIL2 × SIL2 ＝ (100年に1回) × (100年に1回) ＝ (10000年に1回) ＝ SIL4

です。 掛け算って素晴らしい。or回路って素晴らしい。

ただこれは、電子部品のような小さい部品だから多重化が可能なのです。

機械部品（歯車とか）では、こうはいきません。

ただしジレンマもあります。

SILには、故障検知という考え方が、どこまでもつきまといます。

SIL2の部品であっても、その部品が故障したことを検知でき、故障検知するこ とで「製品を安全に停止できる」手段があるのならば、「人命に関わるような 故障」には至らないとできます。

できますが、そのためには故障検知するための部品を追加しなければなりませ ん。

そして、故障検知する部品は、たいていはセンサー、電気部品です。

はて？部品の数は減らしたいのに、安全のために部品を増やすとは？では、そ のセンサーが故障したらどうなるのか？センサーの故障を検知するセンサーも 必要？じゃあ、センサーの故障を検知するセンサーが故障したらどうなる の？・・・以下、延々と続きます。

結果として、故障を検知するセンサー部品は、SIL4にせざるをえないことが多 いです。

センサーがSIL4であれば、[SIL4のセンサー]と[SIL2の部品]を論理的に直列に 組み合わせることで（and回路にすることで）、「製品を安全に停止できる」 道は切り開けます。

ただし、センサーという部品が増えるということ自体の解決にはなりません。

なお、どうしてもSIL4の部品を論理的に直列に10個組み合わせた部品を使わな ければならない場合もあり、その場合は組み合わせた部品のSILはSIL3に下がっ てしまいます。

（[SIL4]＋[SIL4]＋・・・＋[SIL4]＝[SIL4]×10＝[SIL3]）

そういう事情を勘案した上で、「SIL4の部品を論理的に直列に10個組み合わせ た部品」にはSIL3を割り振ってあげるという措置も必要になってきます。

 

Q ソフトウェアSILというのが、まったくチンプンカンプンです。 「ソフトウェアが1万年故障しない」という概念を、どうやって導き出すので すか？

 

A 天が導き出します。

製品の場合は、初めに機械の仕様を定めます。

「この製品は、10年の寿命（使用）を想定する」とか

「この製品は、30年の寿命（使用）を想定する」とか。

その時点で決定です。

部品の場合は、システム内の各部品に割り当てられます。

「各部品がそれぞれSIL0～4のどれであれば、システムとしてSIL4を達成できるか」 を検討して決定し、割り振るのが、『Vモデル』の前半です。

『Vモデル』の後半で、それが達成できているかをテスト・検証します。

 

Q 「SILが達成された」は、どういう状態を言うのですか

 

A SILが実現できていなかった際には、「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということを明確に突き止めることができる状態を言います。

原則的には、自動車を初めとする機械製品に使用される電気電子部品も、 JISB9700-1の枠組みでリスクアセスメントをしリスク低減をし、安全性の確保 を図ることになります。

ですが、そこから話を始めるのでは、電気屋さんやソフト屋さんには敷居が高 すぎます。

「要は、我々は何をしたらいいんだ？」ということで、自動車に使用される電 気電子部品およびソフトウェアの機能安全に特化して定めた規格が、ISO26262 です。

ISO26262の考え方はJIS B9700-1と同じで、「リスクを低減すること」です。

（リスク＝[事故が実際に発生した時の重大度（被害の程度）]×[事故が発生する頻度]）

こういう枠組みは、責任の所在を明確にするという目的があります。

ISO26262をきっちりと理解し準拠していれば、「SILが実現できた」と言える 枠組みになっています。もしも製品のSILが実現できていなかった際には、 「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということ を明確に突き止めることができる、という枠組みです。

たとえば、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、SILが実現できません。割り振った人が悪かった、とい うことになります。

「それじゃあ、結局は人の能力の良し悪しによって製品の安全性が左右される じゃん！」と思われるでしょうが、そうではありません。

認証という話があります。

認証は製品自体のみに行われるのではなく、「製品の安全性に関わる組織」に 対する認証も含まれます。組織内のマネジメントによって適切な能力のある人 材を育成し、適切な人材を配置する（組織マネジメントの）システムが構築さ れているかを監査し認証します。

ですから、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、「そういう人をその業務に携わらせたのが悪い。組織マ ネジメントのシステムの、不備」と結論付けられます。

認証の話に首を突っ込むと、「メーカーに認証を与える機関」に認証を与える 機関やら、『「メーカーに認証を与える機関」に認証を与える機関』に認証を 与える機関やらといった、何がなんやら分からない話が待っています。またし ても、長ーい説明に突入してしまいます。

 

Q なぜ「SIL」の分かりやすい本や解説がないんですか

 

A 製品の安全性に関わる業務をしている人は、忙しすぎるからです。

製品の安全性については、部分的に理解をしている人は多くいますが、それで は全容が語れないのです。全容を理解して語るには、基本原則から実務（具体 的に何をすればいいの？）までを、浅く広く知っていなければ難しい。予備知 識として知っておかなければいけないことが多すぎます。

そして、そういうことをやりたがる人は少ない。いや、仮にやりたがる人が多 かったとしても、多くの人が予備知識を身につけるには、時間がかかりすぎて （コストがかかりすぎて）現実的ではない。「ごく少数の、知っている人だけ が知っていれば良い」という状況になっています。

「分からないことがあれば、そのごく少数の人に尋ねればいいではないか」と。

なので、「具体的に何をすれば良いか？」を尋ねてくる人に回答やアドバイス を与えることだけで忙殺されます。ちょっと詳細に背景や目的まで解説しよう としても、すぐに「もういいや」と言われます。メーカー内でもそんな状況な のに、社会に向けて一般の人に説明しようとすればどうなるか。途中で「ああ、 もういいや。なんやら分からんけども、メーカーでしっかりとやってくれれば いいんだから」と聞くのを諦められるのが必至。

だから、「忙しい」のと「解説を理解してもらうことを諦めている」のが、解 説をしない理由です。

こぼれネットへ戻る