シンドラーのプログラム・リスト

10 KILL

KILL >1

エラーログ：Null Pointer Exception

人がシンドラーねんで！

もうアホかと

NIKKEI NET：主要ニュース
　シンドラー社によると、1991年から93年に出荷したエレベーターに搭載されたプログラムにミスがあり、ドアが完全に閉まる直前に「開」のボタンを押すと、扉が開いた状態でかごが動く欠陥があった。
http://www.nikkei.co.jp/news/main/20060616AT1G1602M16062006.html

>19 ：Ψ ：2006/06/16(金) 17:07:27.55 ID:4Ty1UdGv0
>テレ朝
>開いてから？（聞き逃した）０．２５秒後に「開」ボタンを押すと上昇するーーーーーｗｗｗ
>
>ひでーーミスだ

十分な開発期間を与えないから

意外とメモリリークだったりしてｗ

不覚にもちょっと笑ってしまった

あぼーん

int elevatorMove(int closed) {
　int move;

　switch(closed) {
　　case FALSE: // ドア閉じてない
　　　move = 0;
　　case TRUE:　// ドア閉じてる
　　　move = 1;
　}

　return move;
}

こういう処理が 0.25 秒毎に実行されている。

�@ 開くボタンが押されて、移動中じゃなくて、ドアが全開じゃなかったら　→　ドア開ける
�A 移動先があって、ドアが全閉なら、移動させる
以下続く・・・

ちょうどドアが閉まったときにボタンが押されると、
�@と�Aの処理がこの順で実行され、ドアが開きつつケージの移動が始まる。
自転車挟み込みはまた別のバグだな。

bool checkDoor()
{
　　return (bool)(rand() % 2);
}

ってか、同期処理に失敗してるんだろ。
もともとのOSがおかしいんじゃないか？

この程度の制御にOS使わないでソ。
っていうかOSが載る様な「コンピュータ」とは違うデソ。

うーん。
こんな処理に同期云々なんて出て来るもんだろうか？
俺には単純に状態遷移に失敗してるようにしか見えないけど。

いいか、お前等、
エレベータのドアを閉めてから動かすのも
エレベータのドアを閉めないまま動かすのも
自由だー！（犬井ヒロシ）

>>15
おれのOSの概念がおかしいのか。
まあ制御プログラムなんてほぼOSだしな。

言い換えれば、制御プログラムには同期処理機構がないのか？

>>16
まあ、そうとも取れるけど、
0.25秒以内のときなら遷移するなんて普通作らないでしょ。

>>19
なにそれ？
0.25秒って？

ドアの開閉とエレベータの上昇下降だけに的を絞れば、
エレベーター１つしかないのに何と同期とるんだよｗ

状態遷移をするオブジェクトが一つしかないのに同期云々の問題が出てくるのはおかしいんじゃね？

>>18
プログラマブルコントローラーとかを使う。
ラダーとかそういうもので図面の様なプログラムを書く。
もちろんそれでエレベーターだろうが産業用工作機器だろうが
ちゃんとプログラムすればちゃんと制御できる。

0.25秒に1度制御をしていて、「ドア閉じ完了」と「開くボタン押し下げ」が
同時にセンスされたときのロジックが不良だったんでそ。

昨今の日本人プログラマなんてそんなもんだよね。
値幅制限を越えた注文は約定前でもキャンセルできないなんて大バグもあったし。

>>21
>エレベーター１つしかないのに何と同期とるんだよｗ

>ドアの開閉とエレベータの上昇下降だけに的を絞れば、
この二つ

意味不明なプログラム組むんだな。

基本的にエレベーターなんて動いてる状態と止まってる状態しかないわけで
動いてる状態ではドアのプログラムなんて動かさなきゃいいわけで、
止まってる状態から動いてる状態への条件判定と
動いてる状態から止まっている状態への条件判定ぐらいしか
気を付けることなんてないと思うんだが正直。

>>24
なろほど。こういうときにはどうする？

・ドア全閉検出センサー　ON（閉じている）
・行き先階指定　アリ（現在階とは異なる）

ケージを動かす？動かさない？

それぞれの装置に関してオブジェクトとして考えてて、
勝手にマルチタスクに動いてると思い込んでた。

動かしてるのは1つだけなのか。

>>23
それは２つに見えるけどエレベーターの状態としてみたときにその動きは１つだ。
書き出すと

ステータス動：閉
ステータス止：開
ステータス止：閉
ステータス止：開→閉
ステータス止：閉→開

でステータスとしては１つであって２つはいらない。
ここで設計者がとんでもないウンコでエレベーターの上昇下降とドアの開閉を別のステータスで管理したままで
１つにまとめるプログラムがなかったとすれば、不幸としかいいようがないがなｗ

メインのプログラムにステータスを制御する変数が２つある時点で
俺が糞と認める企業の品管すら通らないと思うがな。

>>27
なるへそ。

ステータス止：開→閉
ステータス止：閉→開

この状態の概念がなかった。
それで状態遷移か。

>>29
制御系だとこういう状態を１つ残らず書き出して一覧で提出しなきゃいけないから普通は起こらないし
まず、聞いたこと無いけどね。そう考えると、日本とかアメリカってまだまだ先進国なんだな。

予想通り立ってたな、このスレｗ まぁマ板に立つと思ってたんだけど。

>>22
昨今って、これ結構前の仕事だし。

１９９０年代っつーとあれじゃね？格闘ゲームはやってた頃だから、
プログラマが「キャンセル技」使えるようにしたってことじゃないのかなあ

昇竜拳＋昇竜拳うめぇ

これってバックドアってやつ？

シーケンサじゃなくて？

だからコボルはやめとけって言ったのに

>>11のコードがあまりにも低レベル過ぎて笑った
こういうのが仕事するからシンドラーみたいなことになる

>>38
神降臨

>>38
マジで言ってるのか？

おれにはどう考えてもネタコードにしか見えないんだが。

「運用でカバー」ってことで。

２ちゃんねる発エレベーター制御プログラムはまだですか

ほらなんかさ、ふだん糞の役にも立たないＵＮＩＸ板の連中が２ちゃんの危機を救った！
とかいう都市伝説もあるじゃん
そーゆーふうに、ふだん糞の役にも立たない２ちゃんがエレベータ業界の危機を救った！
って伝説創ろうぜ！！

>>43
まず、エレベーターの仕様を公開してくれ。

シンドラーエレベーターの工程モデル↓
基本設計無し
詳細設計無し
いきなり製造(coding)
単体試験１日
結合試験　住民が試用してdebug 作業

シンドラーのplatformて何を使っているのか？
ITRON、組込Linux、独自のMPU？

class Elevator {
　　boolean isMoving;
　　boolean isOpened;

　　void openDoor() {
　　　　if (isMoving) {
　　　　　　return;
　　　　}
　　　　if (isOpened) {
　　　　　　return;
　　　　}
　　　　// open door
　　　　isOpened = true;
　　}

　　void closeDoor() {
　　　　if (isMoving) {
　　　　　　return;
　　　　}
　　　　if (!isOpened) {
　　　　　　return;
　　　　}
　　　　// close door
　　　　isOpened = false;　　　　
　　　　isMoving = true;
　　　　// move to another floor
　　}
}

int Age( bool dir )
{
　Sage( !dir );
}

int Sage( bool dir )
{
　Age( !dir );
}

>>30
今問題になってるの0.25秒で〜って機種は、日本エレベータ時代の
製品だから、機材もプログラムも日本製だと思う。

>>41
内容ではなくコーディングのことを言ってる

まちがえた
>>40
ね

>>47
いみがわからん

？？？？

>>49
>こういうのが仕事するからシンドラーみたいなことになる
ってのは >>11 自身の批判を含めているのか？ってことなんだが。

釣られてる？

言い訳臭はにおってくるが
何が言いたいのかわからん

>>53=49 か？
とりあえず、質問に答えてほしい。

│
│ 　 ドア閉確認 　 　 　 　 　 行先床到着 　 　 　 運転許可
├───┤├───┬───┼┼───────◯
│ 　 　 　 　 　 　 　 　│
├────────┘
│
│

│　　　　　　　　　第二地点　　　　減速地点（第一地点）
│ 　　　　　　　　　○〜　　　　　　 ○三
├───┤├───┬───┼┼───────○ 開始
│　　　　　○落下地点|
├────────┘
│
｜

ドアの開閉センサが "開" の時にはハードでエレベータが
動かないようにすればいいことだと思うんだけど。
普通、こんな大事な部分はハード的にロックすると思うんだが。
日本製のエレベータはそうなっていないのかなぁ。

昔、ある搬送装置のアームをアーム取り付け部からモーターからドライバソフトまでまとめて精密機械メーカーに発注した。
実際にアームを取り付けて動かしてみると、過負荷における脱調や慣性によるオーバーランが発生することがわかった。
それを説明した上で、リミットセンサーを設けてインターロック回路を付け加えるよう指示を出した。
修正に時間が掛かり、その後最初のテストをエンドユーザの前でアームをつけて行なった。
果たせるかな、アームはリミットセンサーを遥かにオーバーランして止まった。
メーカー担当曰く「指定パルス分モーターを制御した後はリミットセンサーを監視していませんから当然です」と。

今回のシンドラーの一件ではこのメーカー担当者のアホ面とエンドユーザの呆れ顔を思い出した。

なんでも電子的にやろうとするとだめだよな。
>>57のように機械的にロックしなきゃだめぽ。

Javaで組んだなこりゃ

おさむい言語アンチまで寄ってきたw

>>58
どのタイミングなら監視してたんだｗｗｗ

>>12の
>�@ 開くボタンが押されて、移動中じゃなくて、ドアが全開じゃなかったら　→　ドア開ける
これがおかしくね？
開くボタンが押された場合「停止中で前閉フラグが立ってなかったらドアを開ける」じゃなきゃ、そりゃ開くと同時動くだろ

入力： 内に「開」「閉」「階」、外に階毎に「▲」「▼」ボタン
　　　　現在の階、扉の開閉状態、扉の異物挟み込み状態（ハードで対応？）

出力： 上昇、下降、扉開、扉閉、現在階表示（ハードで対応？）


こんなもん？

FAの制御系で、0.25秒以内と言われてるからPLCがバグってたんじゃないかなぁと思う。
ラダーのプログラムで偶にすごいヤバイ作り方する人もいるし・・・

南無三

>>20
ttp://www.yomiuri.co.jp/national/news/20060616it13.htm
これらのエレベーターはプログラムの欠陥により、
ドアが閉まってから０・２５秒以内に「開」ボタンを押すと、
ドアが開いた状態で最上階か最下階まで昇降する恐れがあるという。

もう組み込みのやつらは信用できません

だから境界テストをしろとあれほど…

古いシーケンサでステップ数多いとと1スキャン250msとかはありそうな気はするｗ

>>67
最近はパッケージのやつが流れて来てるしなｗ

age

エレベーターにPLC使うかぁ？
マイコンじゃないのか？
漏れは建設中のビルで使う仮設エレベーターのプログラムを作ったことがあるが
マイコンだったな。

> 欠陥は９３年に判明し、

最近じゃねえじゃん

>>67
シンドラのは日本産なのか

モーター動かす出力回路に扉全閉を入れればいいだけだろ

具体的にどういうバグだったのかコードを読んでみたいんだが……

具体的な中身も知らずに「こんなの簡単だろ」「こうすればいいだろ」とか言ってるようなやつらがプロジェクトの責任者だったりすると致命的だな

アレだ。
扉が開いていると、ハード的に棒状のものがどっかに引っかかって
動かなくなるようにしてしまえばいい。

プログラム改修後の点検時に一部の基盤を旧バージョンのものに取り替えてしまった……ありえね
どういう管理してるんだ

なんでもプログラムのせいにしやがって。

>>78
雨戸みたいに、扉の一部が壁側の溝にはまり込みながら開く構造にすればいいかな？

>>80
そんなこと言ってないでほら保守保守。

>>79
捏造と思うぞ。
バージョン管理の担当をスケープゴートにすることで
本当の問題を隠してるんだろ。

>>83
違うよｗ
きっと担当者は工場出荷時の状態に戻すボタンを押してきただけでＦＡｗ

組み込み系のＰＧは馬鹿ばっかだからな
落ちこぼれの吹き溜まり・・・

０で割り算させたときの処理ができていなかったんだな

金かかってないだけでしょ。
安価がウリ、だから政府系・自治体系での採用が多いｗ

ウチの会社、いまちょっとした模様替え中してるんだけど、
工事業者が手違いでエレベータ止めちゃって中に2人閉じ込められちゃったｗｗｗ
結局エレベータの不具合ではなかったらしいけど、
時期が時期だけにビル管理業者は冷や汗かいてたな。

無関係sage

＞１０
？

>>10は何があったんだろう……

10って何書いてあったっけ

>>10
あぼーん

>>84
俺も不思議に思ってたんだが、それなら納得出来る。

本当にありがとうございました。

きっと>>10にはシンドラー製エレベーターのまだ発見されてないバグがあったんだろ
それがシンドラーの陰謀で…

なぁ。ドアが開いていたら物理的に動かなくする方法って
ちょっと考えれば誰でも簡単に思いつくよな？

なんで100年以上も前からあるエレベータが
そういう構造になってないんだ？

特に、コンピュータ制御されて無いころの単純なエレベータなら
安全対策機構として入れていたと思うんだが。
コンピュータなら安全だと思い込んで、なくしたのか？

場所食うからでしょ。

>>85
馬鹿が。組み込み系のバグに対する厳しさは他の系の比じゃないことが良くわかるだろ。
後から直せば済むようなもんとは違うのだよ。

エレベーターの裏技
ttp://homepage1.nifty.com/crux/evcancel.html

>>96
開いたドアが収まっている所の空間があれば十分だろ。

>>97
数台以外は、後から直して済ませたんじゃなかったのか？ｗ

扉に籠＋人間を支えられるだけの強度をもたそうというのか。

>>101
天井はそれだけの強度を持っているわけだが？

せめて2系統以上でチェックするようにしてくれ。

ドアが電源スイッチになってればおk

>>104
一瞬頭良いような気がしたが、
それだとドアに挟まれた人間に悲劇が。

電源入りっぱなしか切れっぱなしだな

ドアの開閉は手動なんだよ。

俺がプログラムしたエレベータならドアでガッチリ挟んだまま離さないぜ！
ただし、２０代女性に限るが。

>>107
ドアの電源は別系統なんだろ。

明日この時間にはテポドンが

北朝鮮を

>>109
じゃあ移動中にドアが開いたりしないように、
ドア用電源のスイッチはケージ側につけておこう

ちなみに言語は何だったわけかなぁ？
アセンブラ？？？

ＤＯＳベースが多いらしいね

どうせどっかのフラグが足りませんでしたってオチ・・・

組み込み式のテストで昔、ETCのやつで
新車1台お釈迦にしたやつは見たこた〜あるけど

あれ以来のすごい出来事だよ

さすがにエレベーターにパソコンが内蔵されていることなんてないからパソコン用OSは無い。
マイコンなら開発環境はMS-DOSまたはDOS窓の可能性大。
エレベーターのように短期間に何十万台も売れる可能性の無いものはアセンブラは普通使わない。
C言語だろうよ。

あああ〜〜〜 ソースコード読みてぇ
どんなバグだったのか気になって気になって気になって気になって

やっぱ、長時間安定動作っていうのを考えたらLinuxとかじゃねぇの？
でも大量出荷ってわけでもないだろうからそんなにメモリケチらないんじゃない？
エレベーターの値段に比べたらコストなんてそうかからないだろうし。
Ｃぐらいは余裕で動くもの載せてると思われ。

>>117
だいたい、予想できるからいいよ。
俺はステータスを制御する変数を昇降と開閉で２つもってて
その同期とか妙なことやってて死んだんだと思う。チーン！

Z80のオリジナルボードで十分そうだが

>>118
組み込みLinuxは大した安定性ないよ
起動も遅いし、
リアルタイム系だと普通はDOSでしょう

>>118
簡単なスケジューラがあれば動くものにわざわざLinuxなんて重いOS使わないよ。
そもそもLinuxが安定しててもアプリが落ちたら一緒だから。
Cが余裕で動くって表現もおかしいぞ？

>>119
扉オープン状態で昇降するのはわかるが
なぜブレーキが解除されっぱなしになるのか。
なんの処理に突入しちゃったんだろうか

>>121
最近はitronが普通だと思ってたけど
DOSを積むこともあるの？

>>122
>Cが余裕で動くって表現もおかしいぞ？
それは別にLinuxに関連した話じゃなくて、
エレベータの値段を考えたときに組み込み系に
よくある糞メモリや糞ＣＰＵを使わないだろうって思ったんだけど？
どうとって変だと思ったの？

>なぜブレーキが解除されっぱなしになるのか。
同期云々の問題なら予想外の数値を指した時点で
アクセスバイオレーションだかなんだかよくわからない状態になってもしょうがないっしょ。
一度吹っ飛んで次にプログラムが起動するまで制御不能になってるのかもね。

エレベータの制御プログラムに一体どんな複雑なメモリ管理が必要なのか
組み込みの素人にはとんとわからん。
最近のビルは総階数が動的に変化するのか？

>>124
ちがうでしょ。
もし、プログラム組む奴がどうしようもない馬鹿で
ドアの昇降と開閉ごときでそれぞれにスレッド使ってたらもう予想外の動きした時点で吹っ飛ぶでしょ。
想像力が足りてないぞ。
また、またＣ言語ならポインタがメモリ上の妙な位置を指すことだってあるし、
もし、こういう組み方をしてたら、バグってからの動作は誰にも予測できんな。

基本のプログラム組んで階数なんかはDIP-SWで対応するようにしときゃ
毎回専用に組みなおす必要なんか無いのにな

>>123
信号処理とかは複雑なアルゴリズムの最適化でアセンブラ使うこともあるし
メモリ上のデータ配置も工夫が必要だけどエレベータの制御でそんなにリソース使うこと
ないと思ったからCで組んで動かせないことなんてないだろうと思ったんです
世の中には俺の想像を超えた糞CPUがあるのかもしれないが

>116
対象機器でWindowsが動かんからと言ってなんでDOS窓で開発せねばならんのよ
使い慣れてるからどうしても使いたいってならそれでもいいけど

>>127
はぁ？
>>118に付けた>>122のレスの意味を全然説明できてないじゃん。

>>128
でも、WindowsCEとかエンベデッドとかってシンドラー社のエレベータに載ってるのか？
ちょっと前なんだろ？
ちなみに俺は>>116ではないが・・・

すごい馬鹿がいて　大変だね。
トラ技でもたまに立ち読みでもしたらいいよ。

エレベータの制御なんざ配線の手間いとわなきゃ有接点リレーとかロジックICだけで組めるわい。
そんなものにlinuxだのスレッドだの必要以上のCPUだの時間の無駄無駄

>>131
でも、実際それでバグってりゃ世話ないよねｗ
プログラムが原因とかいわれちゃってホント馬鹿丸出しにもほどがあるねｗ

>>129
あなたの言ってるCがC言語のCじゃなかったらゴメンナサイ
俺の勘違いです

C言語で書いて動かないくらいにリソースのきつい
CPUなんて存在しないと思ってるからその表現は
おかしいなと書いたの

リソースの使い方を間違ってる希ガス

>>133
>C言語で書いて動かないくらいにリソースのきついCPUなんて存在しない
そうか・・・まあ・・・そうだな・・・orz

各階のボタンや表示にそれぞれ配線をパラで持ってくるのが嫌でシリアルでやってると思うから、その辺でマチガイがあったんだろうなあと思う。
こういうのはリレーで見えるようにインターロックとるほうが間違いすくないだろうね　リレー焼けてダメになって結局閉じ込められそうだけどｗ

>>136
ええ？でも、記者会見でプログラムの更新ミスですって言ってたんだよ。
何いってるかわからないけど、それもプログラムなの？

>>134
ちょっと自信ないですが
CPUの処理時間はリソースの内には
入らないですか？

リソースは資源だからメモリ容量とかを指す

>>139
とりあえずなんでもリソースって言ってイイみたいです

http://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9

>>140
これちょっと違うような・・・

ふつうに CPU resource とかいうんだが。

>>142
その場合は何を意味するの？

組込みや制御系なんてさっぱりわからない木っ端プログラマは
「ドアが開いてるか閉じてるか」「どのボタンがおされているか」
「カゴの現在位置」「カゴの上昇・下降速度」などの状態が、
レジスタを参照するかAPIを呼び出すとかすれば知ることができる、
みたいな想像しかできんのだが、この認識は間違っているのかな？

CPUのリソースが足りないっていうとタイムシェアリングで人大杉みたいなかんじですか

簡単に例を説明すると、あるメモリ番地を読むと各スイッチのステータスが取得できて
あるメモリ番地に書き込むと命令を送れる、みたいなかんじ（メモリマップドI/O)

>>138
CPUリソース、検索して理解した。
処理時間と言うか、CPUの使用率とか占有率のことを言ってるんだね。
自分は使ったこと無い用語だったんで知らんかった。
それでもwikiの説明は変だな。

プログラム誤動作が致命的な結果になるハード設計が問題なよーな。

>147
制御系で問題になるのって応答時間でそ。

本当に組み込み系に関するまともな知識を持ったやつって少ないんだなw
エレベータの制御にLinuxなんか使うわけないだろ。
オープン系のやつらが組み込み系で使えないわけが良くわかったよ。
シンドラーのエレベータもどっかのオープン系から来たやつが組んだんだろうよ。

>>149
エレベーター制御と管理センターへの通信と、同じCPU上で動作させてるワケねえだろ

>>150何が言いたいんだ？

>>151
ネットワーク部分は、オープンソースが得意だろ？

ｲﾐﾌﾒ

日本エレベーター時代のエレベーターがまだ稼動してたら
同じ事が起きるのかな？

もしかして制御ソフトは同じのを使いまわしているが
シンドラー時代になって制御ハードのほうがグレードアップしたもんで
これまではクロックの遅さなんかが幸いして表面化しなかった
タイミングの隙間が出てきてしまったとかかな・・・

指先一つでダウンさ。
YOUはショック?

俺は結構ショックさ。

>>128
ターゲットはマイコンでよくOSなど搭載されている必要はない。
開発環境はMS-DOS用のものが今でも多いし、それで十分。
Windowsアプリを作るわけではないのだから。
Windows上の開発環境は無いことも多い。
Windowsアプリの経験しかない人間には組み込み系のプログラムは理解しがたいものだろう。
想像も付かないと思う。
自分でCPUボード買って配線して電気製品を作り制御系コンパイラやアセンブラを使いROMライターでROMを焼くなんてことは君らはしたことないんだろう。
開発環境は需要が少ないから個人では手に入りにくく手に入っても高価だ。
開発環境といってもただのコマンドライン。
仮にWindows用であってもDOS窓で使うことになる。
ccとかmakeとか打ってコンパイルするわけだ。
金のある会社ならICE(アイス)というハードウェアのデバッガも使う。
まあ、知識ゼロでエレベーターのプログラム作ったことない奴が想像だけで語るなって。
君らは「たまごっち」のようなおもちゃやジュースの自動販売機の中にはPentiumを積んだパソコンが入っていると思いたいしそれしか想像できないんだろう。

これくらいならポケットコンピュータでも制御できるくらいのシステムですよ

>>157
高校の時(10年以上前)、電子科の授業でポケコンを使って、
ミニチュアのエレベータを制御するプログラムをかかされたよ。
確か、開発言語はZ80のマシン語だった。

>>156
組み込み系の仕事やったことあるけど、普通にLinux載せてC言語で組んでたよ。
で、できたプログラムはPCから普通に何度も書き込める。
アセンブラも使わなかったし、ROMライターなんて知らん。

君のいう環境と俺の知ってる環境で何が違くてそうなるの？
また、エレベータのプログラムとして可能性があるのはどっちなの？

>>156じゃないけど、システムがLinux（というかOSの機能）を必要とするかどうかじゃないの？
エレベーターの制御程度に汎用的なOSの機能は必要無いかと

>>159
組み込み系と言った場合多くは>>156
何が違うかといえばターゲットシステムが違う

>>158 の 環境を多少豪華にした程度の物もゴロゴロある
エレベータ程度ならx86にITRONでも積んでたら立派なもんだな

複数台のエレベータを備える大規模なビルになると、エレベータの配車(w)を木目細かく制御する必要がある。
そうなると、ビル管理との通信を含めてOSが使えるシステムを載せることになるだろうとは思う。
しかし、1-2台を連携させずに制御するだけならボードコンピュータで充分で、実際TVニュースの映像で見る限り
「プログラムの入れ替え」と称して基板を入れ替えている。

>159はルータか何かの仕事でもしたんでないかい?
あれは組み込みとしては有り得ないほど贅沢で、PC並のシステムが要求されるし記憶もFlashメモリだろう。

大学時代の研究室の先輩は今エレベータ業界で働いているというが
どうしているんだろうなあ…
今頃大変なんだろうな……

>>162
郡管理システムですな

>>162
それ、面白いけど建物の建設時に数が決まってしまう
エレベータみたいなのに採用するメリットあるのか？

単純な、それこそLinuxだろーがWindownsだろーがご自由にな
ハイスペックなホスト＋ボードコンピュータ並のクライアントで十分じゃね？

素人から見てどうにも理解できないのは、
ソフト面をそこまでケチって何の意味があるのかということだ。
エレベータともなると、ハードには数百万単位かかってるんでしょ？
しょぼいマイコンとPC並のCPUでは、差は10万もないだろう。
携帯機器じゃあるまいし、低電力・省スペースのCPUでなきゃならんと
いうこともないんだから。

安全性だの耐故障性だのを考えて設計されたものはハード、ソフトともにバカにできないくらい高い。
そのしょぼいマイコンだってそういうのを考えれば数十万するだろうし、
ソフトだって(まともにやってれば)数十〜数百万するだろう。
(安く請け負うところはプログラマーの質が低いことが少なくない)

それが販売価格に跳ね返ってくるときには何倍にもなるわけだし、価格競争もあるから・・・・・・・・？

スーパー競馬ちゃんと福島いってんだな

スマン、誤爆した

>>167
それでも合点がいかないほどエレベータの値段のほうが高いからだろう。
ＰＣ何台買えるんだって話になるし。

下手にOS乗っけるよりシンプルいずベストなわけで

>>171
でもアプリだけが落ちたときにＯＳは残るよね。
それで何か手を打てるならそのほうがいいと思うんだけど。

>>172
その為にウオッチドッグがあるんだよ

アプリｗｗｗｗｗ

このスレ読んで思ったこと

分野外のプログラムを組んじゃいけない

>>118

一定動作の後に毎回リセットされる

>>175
今から５年ほどまえに組み込みブームとかでホスト系あぶれやオープン系で使えねえ連中を大量に組み込み系に送り込んだらしい

>>175
それじゃ成長がないな。
俺が思うにエレベータみたいな高価なものでもマイコンみたいなプログラムが動いてるのは
要はそのまわりにいる技術者がそのやり方しか知らないからだと思うな。

本当はここまで品質が問われる製品ならユーザーがどう使ってるか？とか
どういう時間帯にどういう操作がされたか？とか、
エラーが起きたときや電源断が起こったときのエレベータのプログラムが上げたメッセージとか
そういう統計データをデータベースに登録したり、管理者に故障原因を通知する機能があってもよくね？

まあ、この事件をきっかけにこれからこういうもんの需要が増えてくると思うけど。

ないと思ってるのはなぜだろう

世間知らずだからじゃない？

>>179
シンドラー社の記者会見で結局エラーの原因はわからず
管理者にそれがエラーとして上がっているとかいないとかいう話も無かったから。
それにこういうシステムになってるならもうマイコンがどうとかって話も無いんじゃない？

と単純に思った。

もちろん、エレベーター自体はマイコンで動いてて、エラーログや操作ログだけは別の場所に保管していて
数分に一度動くログをデータベースに保存するプログラムはまた別って感じで動いてたら
いつまでたってもジリ貧だけどｗ

つまり

エレベータ制御ーマイコンＰＧ−ログーログをデータベースに書き込むＰＧ−データベースー管理端末

って構成ってことな。

お前らに任せるとドライヤーとか目覚まし時計とかにもPentium 4載せそうだな。

小学校で習ったぜ

>>182
penちゃんはハングしないよ

>>182
いや、大量出荷で１つのＣＰＵのコストが確実に損益に影響を与えるものであればわかる話ではあるのだが、
エレベータとなるとどうも合点がいかなくてな・・・

>>181
自分が聞き齧ったたった一つの現象をもって
その他全ても同じだと思い込むのは
素人プログラマの悪い癖だよ

>>186
じゃあ、やっぱりＶＢなんかで制御されてるエレベータもあるかもしれないって感じ？

>>185
豪華なハードでごついOS載せたって、今回みたいな問題は起こるんじゃない？
むしろ問題がより複雑になる場合の方が多いと思うけど。
それに、全体のコストに埋もれるからといって
シャンデリア搭載したり、漆塗りのボタンにしたりするのはアホだろ。

便所に100Wの電球は要らないってことですな

>>189
まあその便所も最近は快適装備ものすごいけどなw

Linux/Windows どちらでエレベータを制御するにしても、パソコンの HDD と mother board の組み合わせだったら、そんなエレベータには乗りたくない。一年に一回以上は、閉じ込め事故が発生することになる

>>181
>178と同一人物かな。
>162でも書いたけど、大規模なシステムならDB管理くらいしているかもしれない。
しかし、エレベータ1基(む、そう言えばさっきは間違って台と書いたな)では
そういう管理まではしないのが普通だと思う。
#理由は兎も角ね。

エレベータ一基の価格っていくらぐらいだったかなぁ。興味があるなら調べるけど。

マイコンでもGUI上でC言語でプログラミング、できたイメージを
シリアルでROM転送ってとこまでできるのもあるけどな。
エミュレーターもついてるからデバッグもある程度までは手元でできるし。

実際の現場がどういう環境なのかは全く知らんけど。

オープン系はPCがあれば誰でも勉強できるが、
組み込み系は組み込みの仕事やってないとx86以外のCPUでプログラム組んだり
各種ICを直接操作したりという経験をすることができないからなぁ。
最近は手軽に個人でも扱えるCPUも増えてきたが、仕事で扱うCPUはもっと高性能になってるし。
組み込み系技術者が不足するわけだ。

>>194
え？で、結局何がいいたいの？
最近はどうなってるの？
仕事で扱う高性能なＣＰＵもやっぱり組み込みっぽく組まないと駄目なの？
例えば、Windowsエンベデッド＋ドライバっていうようにはいかないってこと？

組み込み用OSとはいえWinCEに命預けたくないなー

399 名前：Be名無しさん[sage] 投稿日：2005/03/22(火) 19:44:39
汎用OSは重要なコンピユーターには使えない。専用OSでないとね。

402 名前：Be名無しさん[sage] 投稿日：2005/03/23(水) 01:21:06
>399
専用つーか枯れたコードを使うと思うが
ttp://hotwired.goo.ne.jp/news/news/technology/story/20040218303.html

エレベーターも作っている某大手企業でソフトの仕事してたけど…
>>11のネタのような初歩的な誤りは社内のデバッグで案外見つかってたな。
おまい本当に技術者か？みたいな。
普通は客先に出す前に致命的なバグはほぼ100％潰せるんだけどね。

今ごろ気づいたけど、
Windows CE ってリアルタイムOSだったんだな。

>>199 違う
リアルタイムOSのリアルタイムの意味を調べとけ
LinuxもリアルタイムOSとは違うぞ。組み込み用にリアルタイム性を持たせたLinuxもあるがな

RT-Linuxだっけ。
カーネル部分の構造がまるきり別物だとか。

最近のLinuxのカーネルはその辺大分チューンされたって話だけどよく知らないや。
どーなの？詳しい人。

RT-Linuxはスケジューラ周りに手が入ってるんです。
RT-LinuxよりlinuxとuITRONのハイブリッドがよさげだけどなぁ

ところでエレベーターはどこ行ったん？

あぶないのでエスカレーターに換えました。

今回のはいくらなんでもひどすぎる。制御ソフトのバグだけとは思えない。
組み込みハードの設計も素人だったんじゃないかな。
PC組み立てる感覚でエレベーター組み立てられたらかなわんよ実際。
電源ノイズによる暴走とそれに対する対策の甘さが原因となっているケースが５件はあると大胆に予想してみる。

こう言っちゃ何だけどさ、エレベーターのプログラムなんて、新しく組みなおす必要、あるの？
機械的な部分には、裏に隠れて、日々新しい設計が導入されてたりするの？
そーいうのが無い限り、きょう納入されるエレベーターが、10年前のプログラムで動いてても
一向構わない気すらするんだけど、門外漢だからそう思えるだけのことなの？

>>205
制御用の部品が製造中止とかでプラットフォームを移行したときに作り直す必要が生じる・・・ぐらいじゃないの？

ageてまった・・・スマソ

それだけだとアレなので

206のトリビア
間違って階数ボタンを押したときはダブルorトリプルタッチで消せるエレベーターがある。

>>159
http://www.rasteme.co.jp/product/z80/ukc81601/ukc81601.html
例えば、こうゆうのを自分で買ってきて自分で配線して自分でROMに焼いて自分だけのオリジナル電気製品でも作れるようになったら理解できると思う。
エレベーターのプログラムというのは正直単純でたいそうな処理は必要ない。
また、ソフト面だけでなくハード的に安全対策ができる。
例えばモーターの電力線が扉が閉じた時に入るスイッチにつながっていれば
扉が閉まらないとモーターは動かない。
扉が閉まらないと動かないという処理をソフト的に入れなくてもハード的にそうできる。
大量生産するものはコスト削減のために汎用OSはないことが多い。
三菱やシンドラーがどうやっているかは知らないが俺が作ったことがあるエレベータープログラムは
LinuxやWindows CEやTRONなどの汎用OSは無し。
パソコン並の処理を求めるならこれらの汎用OSを使うのもわかるが
エレベーターはやる気になれば4ビットCPUでも作れそうなもの。
そんなボロCPUには汎用OSはのらない。
せいぜい金かけても68000でよく汎用OSがのるようないまどきの32bitCPUを載せる意味など無い。
なぜかって言われても
ジュースの自動販売機の中のCPUは4ビットCPUでよく、よくやっても8ビット。
わざわざジュースの自動販売機にPentium4を積んだパソコンを入れる必要がないということだ。
でもアプリ専門プログラマーにはパソコン入れればいいじゃんという発想しかないんだろうな。
わかるよその気持ち。
汎用OSのAPIはエレベーターには全て必要ないんだよね。
のせる意味がない。ファイルシステムも仮想メモリも必要ないんだから。
DOSはディスク・オペレーション・システムの略だけど
ディスク持っていないエレベーターにそんなものは要らないだろ。
ディスプレイも無いから描画系APIも必要ない。
おまえらなら何のために汎用OSを載せる気だ？
組み込み系の俺にはさっぱり理解できないね。

逆に質問なんだけど、エレベーターって、集客率の統計のための集計窓口とかのためには使われないの？
フロア別の乗降具合をサンプリングしたりとか、集合店舗とかなら需要ありそうな気がするんだけど。

シンドラー社はテスト項目にプログラムテストを入れてない気がした。
ドア半開きなんてすぐ見つけられるバグだよな。

> 　さらに、９３年にプログラムを書き換えて問題を解消した４９基のうち、４カ所の計
> ６基は、それぞれ０３〜０４年に制御装置を交換する改修工事をした際、誤ってミスを
> 含んだ改良前のプログラムに書き換え、元の状態に戻してしまった。

訳が分からんなぁ。

飛行機、車、エレベータ等、人命に関わるプログラムにだけは
バグ出さないでおくれよ>>プログラム板の人達

バグに言ってくれ。
こっちはベストを尽くしてるつもりだ。
概ね。

>>211
「誤ってミスを含んだ改良前のプログラム」って、
こんな言語道断なバグ入りのものが保守部署の手に渡る時点で
シンドラー社の開発体制を疑う。

>>209
高層ビルとかに入ってるようなエレベータでかつ複数な場合は、待ち時間を少なくする為に若干インテリジェントな形にはなっているらしい。

>>214
開発っていうより、運用・管理だよね。
ISO取り消しされても文句は言えないと思う・・・

エレベーター業界って、独立系保守会社には設計図どころか
メンテナンス用工具も渡さない世界らしいですから。

それでメンテしろって言われてもねぇ。

>>211
「誤って古いバージョンのバイナリを入れてしまいました」

あり得ない（修正済みのはずの）障害が顧客に発見されたときの常套手段。
必死で修正して　←　いまココ
新しいのと入れ換えました、と言って闇修正する。

>>216
といっても別に無理矢理やらせてるわけじゃなくて、
保守会社の方が「メンテします。できます。やらせてください」って
言って契約取ってるわけで・・・

MSにWinのソースくれっつってるようなもんだよな
独立系のメンテナンス会社の存在自体が問題だと思うよ

>219
メンテナンスの資料を自社以外でも出さないと
いけないというルールがないことが問題では？

>>220
企業秘密を他社に提出しろと？

Winのソースと言うより、SDKを渡していない状態かと。

扉が開いたまま昇降する、非常モード（消防士用）があるのを知らないんだな。

エレベータって回路が分けられてて、電気的に通常モードと非常モードを切り替えるんだが、ﾂﾝﾄﾞﾗｰはそれをケチって単一基板上に両モード入れてたから、上物（ソフト）の不具合で非常モードに遷移したんじゃないかと。

案外エレベータって思ってるより複雑よ？
だからっつってシンドラーの言い訳にゃならんがな。

見えてる動きだけで物事決めつける香ばしいソフト屋がこんなに多いのかと驚愕。

扉が開いたまま昇降する、非常モード（消防士用）があるのを知らないんだな。

エレベータって回路が分けられてて、電気的に通常モードと非常モードを切り替えるんだが、ﾂﾝﾄﾞﾗｰはそれをケチって単一基板上に両モード入れてたから、上物（ソフト）の不具合で非常モードに遷移したんじゃないかと。

案外エレベータって思ってるより複雑よ？
だからっつってシンドラーの言い訳にゃならんがな。

見えてる動きだけで物事決めつける香ばしいソフト屋がこんなに多いのかと驚愕。

その程度で複雑か？

まあでも、当事者じゃなきゃこの程度の認識だよな。

「4ビット,8ビットマイコンで十分」という人が居たり
「思ってるより複雑よ？」という人が居たり、
エレベータ制御屋業界が複雑なことは分かった。

メカトロを知ってる人はいないのかね

たかがモードを２にして複雑というのか？

エレベーター　ソフトなければ　ただの箱

メカだけで動くエレベーターだってあるじゃまいか

今稼動してる箱があるかは知らんが

非常モードになっていたとして、
半開きで昇降してたらやっぱり糞だよな。消防士から見ても。

エレベーターの制御程度で複雑とか言うなよ

結論から言うと、>>33でＦＡだな。

>>231
密閉じゃなくて籠状になってるの、レトロチックでかっこいいね


余裕で腕とか挟まれそうだが

そのとき、小嶋は意外な事を言った。

せめて扉が半開きのままでも昇降できるようにしてみたらどうだろう。

姉歯は戸惑った。

昇降中に「開」ボタンを押しても扉が開かないようにしたのは利用者の安全を守るためだった。

しかし利用者の意志を尊重するために安全装置を外そうというのだ。

無理です。出来ません。

小嶋は思わず叫んだ。

俺たちがやらずに誰がやるんだ。俺たちの手で閉ざされた扉を開くんだ。

男の熱い思いに、姉歯は心をうたれた。

IT技術者の血が騒いだ。

やらせてください。

夜を徹しての設計作業が始まった。

はいはい不謹慎不謹慎。

書いていて恥ずかしくならなかったのだろうか

あーそろそろ暇

スペランカーの話でもしようか

>>223-224 の二十書き込みを見ると

見えてる動きだけで物事決めつける香ばしい香具師なんだろうな

アーケード版のスペランカーも相当香ばしいよな。
酸欠で死ぬ分、ファミコン版よりも貧弱かもしれん。

なんか、シーケンサで書いてないって思ってるやついるんだなぁ。
時代を感じる。
普通の言語で書かれてれば、おばかなエレベータとかそんなに
あるわけないじゃん。
その時々でラダー足していったら、時間が間に合わないことが
あるから、そのあたりじゃねーの？

>>243
この板ですら「シーケンサってなに？」「ラダーってなに？」てな奴らがわんさと居るだろうな。

ごめん、わからない。
解説きぼん。

http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%80%E3%83%BC%E3%83%BB%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF

Cで説明すると、
for(;;){
　create_thread(ラダー１);
　create_thread(ラダー２);
　create_thread(ラダー３);
　create_thread(ラダー...

　join_thread(ラダー１)
　join_thread(ラダー２)
　join_thread(ラダー３)
　join_thread(ラダー...
}

ラダーは
void ラダー1(void){
　if( 接点条件等 ) 接点変化設定
　exit_thread();
}
接点は本当のスイッチだったり、アナログ値だったり
擬似的なスイッチ（一般的な変数に相当）だったりする。
>>55
とかに書いてる様な表記をする。
create_threadしているところからわかるように、
ラダー１の接点変化が直後のラダー２で使えるとは
限らない。
シーケンサはそんなに経験ないから、つっこんでおいてねｗ

>221
はぁ、自動車ならどこの整備工場でもメンテできるでしょ。
それって企業秘密じゃないだろ

>>248
専用工具も無けりゃパーツリストも整備マニュアルも持って無い
メーカーの自動車を「整備できる」という整備工場は怪しい。

オレとしては>>156 >>208 の意見に同意。

組込み系とそれ以外でここまで意識の差があるとは正直愕然としました。

>>250
組み込みの中でハードウェアの制御を行っている部分は汎用OSいらないだろ
だけど、情報端末としての機能を持ってる部分は汎用OSを使った方が良い

最近の雑誌見ると、組込用マイコンでパソコン並みのやつが恐ろしく低価格で売ってるよ。
８ビットマイコンのアセンブラをじっくりと組むより、LINUX組み込んでGCCでサクサクやっちゃえ、みたいな会社が出てきてもおかしくない。

アセンブラと比べればそうかもしれないけど、アセンブラは少数派でしょう。

組み込み系の人間から言わせれば、今回のシンドラーのエレベーター程度の制御で
linuxとかのOSを使うメリットが無いってこと。
「なぜOS、OSと言うんだ」というのが率直な疑問。

汎用OS乗っけてプログラム規模を大きくすれば、テスティングにも工数がかかるし、
そもそもOSのバグで誤動作したときに、OS会社が保証をしてくれるわけでもないので、
使う側はOSが正しく動くことすらもテストしなくちゃいけなかったりで、
汎用OS使うデメリットのほうが大きいのですよ。組込では。

エレベーターなんかはOSが起動するまで待ってられないでしょ
電源オンで直ぐにプログラムが動かないと

　　+　　　+　
　 . ○●○ +　 　
　 （0ﾟ・∀・） 　＜僕、団五郎くん。今日も爆釣だよ！
　 （ つ　 つ

208
> DOSはディスク・オペレーション・システムの略だけど

（´,_ゝ｀）ﾌﾟｯ

>>257が笑ってる理由が解りません！！

シンドラーがエレベータ「程度」の制御すら出来てなかったことが
そもそもの事の発端なわけだが。

>>259
＞シンドラーが
日本エレベータ工業が、じゃないか？擁護するわけではないが。
何かとお粗末っぽいシンドラーだけど、この製品は日本エレベータ時代のものだろ。

>>259
やってみりゃ難しいとは思うよ。
うちの会社のエレベータはFUJITECだが、
５つボタンを押すとキャンセルされる。
が、その後あらたにボタンを押すと最初の１つが生きてて
ランプのついてない階に止まる。
通常動作で変なのはさすがにシンドラーお粗末だけど、
「すら」とか言われる難易度ではないんでないかな。
元のシーケンサが非力なら、それは大変なわけだし。

「籠が動いている時は扉を開かない」
こういう機能はメインのプログラムとは独立に実装されるか
ハード的に組み込まれているものとばかり思いこんでいたよ。

エレベーターの制御程度で難しいとか言ってたら
組み込み系できないんじゃないのか

籠を誤差１ｃｍ以内で止めてみな

そりゃハード側の役割だろ

組み込みLinuxとかブームだからなぁ。
そういう雑誌の煽り文句的な情報に毒されてる人たちはエレベータにも普通にLinuxが乗ってると思うのかも。

>>265
なるほどなぁｗ
シンドラーが、プログラムミスしてもしょうがない時代かもなぁ。

新しい部品とかつけてもアナコンダが認識してくれるんだろうなぁｗ

ばかじゃないのｗ

操作系から駆動系（ハード）に信号出すだけだろ
駆動系にソフト乗っけてる場合もあるだろうけどさ

なるほど。話が通じないわけだ

エレベーターの制御「程度」って言ってるのは、制御信号出すだけなのに、
そんな複雑な処理じゃないだろう？って意味で、
確かに籠本体をソフトで制御するとしたら、制御「程度」だとは思わんよ。

↑
意味若欄

つか、階数ボタンのセンスアップから階数表示の点灯から蛍光灯のON/OFFから、モーター制御から何から何まで１CPUでやるんじゃね？

>>272
エレベーターを一つのハードウェアと考えてだね、
そのエレベーターに出す命令（上昇とか下降とか停止とかドア開閉とか）を制御するのは
そんなに難しくはないだろうってこと。

例えば、今１階に止まってて、１０階で呼び出しのボタンを押されたら、
上昇　の命令を出して、１０階に着いたら　停止、ドア開　の命令を出す。
もしかしたら　１０階まで移動　って命令かも知れない。

ただ、エレベーター自身の移動をソフトウェアで組むのであれば、
移動させると慣性の法則とかあるから、モーターなんかの制御プログラムは難しいだろうと。

>>273
どうなってるんだろうね？
各部分で分けた方が効率は良さそうだけどね。

ま、パチンコ台ならチューリップの開閉からアニメーションから全部１CPUらしいな。
あ、確率計算の部分だけ別載せの既製品CPUだな。

まあ、どっちにしろ、ＯＳがのってようとのってなかろうと
組み込みプログラム自体複雑であることがバグった理由にはならないんだけどな。
だって、そんなに複雑ならそれなりのスペックのもん載せて楽にプログラム組めばいいじゃん。
中の動きがどうだろうとエレベーターの動きは俺等がみたまんまだよ。
上昇、下降、ドアの開閉。
この大まかな動きが上手くいってないのって別に詳細の処理がどうとかって関係無い話でしょ。
これが切り分けられないほど困難な環境であれば、やっぱりそうでない環境にする必要があるってだけの話でしょ。

だから、ただ単に、バグってんだよｗ
いいわけ無用ｗ
残念！（死語ｗ）

最後はオシロでデバッグ・・・
というノリのわかるやつは少なくなったんだなぁ

>>277
だから
>>274の言ってることが理解できんのだろ

慣性まで計算してモーター制御までやるなら
そこそこのスペックのCoreが要るな

その場合って、籠の中に制御盤とモーター制御する制御盤って
別物にならんか？

物理的に独立した物を無理に１個で制御する理由が分からん

と書いてて思ったが、

　そうか籠の中の制御盤とモーター／ブレーキの制御盤の同期のバグか！
特定タイミングの250ms区間の特定操作だけ異常動作するって
デバッグ段階までなら、いかにもやらかしそうな話ではあるな

組込み屋さん達が気にしているのは『機械』としてのエレベータを制御すること、
門外漢のアプリケーション屋が興味があるのは、利用者を快適かつ安全に
運ぶ『サービス』としてのエレベータを操作すること。
階層が違うのだからいつまで経っても話が噛み合わないのもむべなるかな。
まあ、どちらの意味においてもシンドラーのはダメダメだったわけですが。

>>279
>門外漢のアプリケーション屋が興味があるのは、利用者を快適かつ安全に
>運ぶ『サービス』としてのエレベータを操作すること。
なにいってんの？
だれもそんなこといってないんですけど？

MSが全ての電気製品にWindowsを搭載しようと企んでいるからでは？
汎用OSを載せる理由？ Windowsを売るためだろうね。

電動歯ブラシにwin((((((；ﾟДﾟ))))))

CPUからは指令パルス出すだけだろ。
つーか、加減速の設定とパルス数（移動距離）をセットするだけ。
あとはセンサ情報を見て実際の位置とのズレを補正するくらいなんじゃない？

ちょうどいいから、エレベータの設計してみようよ。
動かす訳ではないから、ある程度ははしょって。

機械強度とか、おもりがいくらとか、考えればきりないから、
線引き難しいけどね。
とりあえずＩ／Ｏが届く範囲を考えて、機械的制約は無視しましょう。
コストとか。

ばらばらと思いつくところ。
１．モータの種別と制御。インバータだよねぇ。ノイズ対策は無視。
　　加速度とかどう考えりゃいいんだ？重量とかねあいがあるんだよね？

２．各階という定義。近接センサ、リミットスイッチ、他に方法ある？

３．人命尊重、緊急時という定義。
　　ワイヤが切れた場合とか、中で人が飛び跳ねて重量センサが一定の出力ださない場合とか。モータが壊れた。
　　ブレーキが効かない…これはもしかしたら検出できないのかもね。加速度センサとかないでしょ？

４．待機時の処理。１階だとドア開くとか。２台あって下ボタン押されたらどうするかとか。

５．ドアの制御。各階のドアは開けるときに音がするからやはりモータだよね。５階のモータ壊れてたらどうする？６階にいく？とりあえず？
　　あとドアにはさんじゃう処理。あれどうやってるんだろう。高いのは赤外線でみてるよね。トルク制御？あと、籠とドアの同期。


考えると結構あるな。穴だらけだと思うけど。特に加速のあたりとか難しいな。重量センサが確実に信頼できないとすると、早いエレベータ
では速度センサがありそうだね。重量センサはまんなかにロードセルついてるだけだろうから、エレベータが上下すれば当然読みは変わる。
エレベータで壁にみんなよればたくさん乗れるっていうのはたぶんこれだよね。

５の各階のドアだが、各階のドアにはモーターは無いんじゃないか？
エレベーターのドアと機械的に連動してるのでは？

検討するならエレベータ仕様をまず調べる必要があるでしょうね。

こんなのとか。
ttp://www.mh-he.co.jp/for_houjin/bno/main.html

JISとかも見てみる必要があるかも。
エレベーター会社の資料、モーター関連会社の資料、エレベーター団体の資料、JISくらいかな？

まず要求仕様書を書いてくれってアプリ屋が言いそうですね

>>287
そういうアプリ屋が仕様書どおりに作るから
想定外の事象が起きたりするんでないのｗ

仕様どおり作れば相手は納得するかもしれんが
死んだ客は納得しない。

>>281-282

Windows for Viberator

>>283
パルス出すのはステッピングモーターだけだ。
ステッピングモーターは非常に負荷が小さいものしか使えない。
エレベーターがステッピングモーターで動くわけないだろ。
素人ばかりだなここは。

「CPUからは」と書いてあるんだが。
機器の動作を電気信号レベルで考えることができないようだな。
アプリ屋か？

290はちぬま

バルス！

バルバルバルバル

例のデブ飯野がザ・タワーを作ったとき、エレベーターの
「客をなるべく待たせないゴンドラの動かし方」が難しくて
悩んだらしい。エレベーター会社に問い合わせたら企業秘密で
教えてくれなかったって。

>>295
だからそれは郡管理システムなんだってば
エレベータ自体の制御とはまた別の話

>>290　が一番素人。

>>11
の何が悪いの？

何が悪いのかは知らんけど
引数がbool型ならともかくint型でdefaultが無いのはまずくない？
あと変数moveは要らないような希ガス
そもそもこの関数自体が要らないキモ巣

何が悪いのって、お願いしますよ、もぅ・・・

#define　TRUE　1
#define　FALSE　0

つーかbreakがないのを一目見て気付かないようじゃ
かなりまずいんでね

#define　TRUE　1==1
#define　FALSE　1!=１

#define　FALSE　0
#define　TRUE　(!FALSE)

>>304が一番まともだけどそんな次元の話じゃない

>>302
そこは当然書いてあるだろう
と思いこんで、素で気づかなかった
俺が開発者だったら死人が一人じゃ済まないな

ずっと他の言語使ってたからswitchは勝手にbreakすると思ってたな
>>306
break以外で何が問題？

SUB エレベータ()

DO WHILE 昇降中 = TRUE
IF 昇降中 = TRUE THEN 扉状態 = "閉"


END SUB

すみません書きかけで送信しました
せっかく妙案が浮かんだのに残念です

>>290
お前マイコンから3相200ボルトとか出ると思ってるのか？

ＶＶＶＦって知ってる？

サーボモータが泣いています

>>290
おらおら出てこいや！

>>311
新規の設計で注文だすなら音程には気を配ってくれ。

>>290は自殺したか？

290の人気に嫉妬

>>290 は学生だろうけど就職先はソフトウェアに関係ないところにするべきだ。
知識・想像力が大きく欠けている。
外食産業とかがお勧め。

ソフトウェア産業には、知識・想像力が大きく必要なのですか？

多かれ少なかれ、どの業界でも知識や想像力は必要だな。
それと、知識欲と観察力かな。

>>318
とりあえずUIや外部に近い部分を担当するなら想像力はマジ必須

たまにあるだろ？数字のみの場所に文字入れたら落ちたりエラーが延々出続けるプログラムとか、
CDからコピーしないでその場で実行したり、保存先のUSBメモリが書き込み禁止だとその場で異常終了するプログラムとか

まぁ、普通は設計仕様書やテストシートに記述があるからコーダーで一生を終えるなら要らんかも。
設計仕様所やテストシートを書く上級職を目指すなら、想像力が無いとお話にならん。

>>320
> 数字のみの場所に文字入れたら落ちたりエラーが延々出続けるプログラムとか

290だったら、上司に「おいバグが出たぞ」と言われたら
「そこは数字入れるところなんですよー。文字なんか入れられたら困りますよ。アホですか？」とか言いそうだな。

基本的知識が無いのをごまかすことばかり考えてもだめですよ
アプリのプログラマーは取りあえずだまっておいたほうが恥かかないですむと思うが。
機械制御プログラマーが見たら笑える話ばかりだよこのスレ。
ステッピングモーターとサーボモーターの区別が付かないバカは退散しろ
直流モーターと交流モーターの違いもわからんのだろうなどうせおまえらは
勉強してこいよ。
このスレの99.9%は何も知らない奴の笑えるバカ話。

とりあえず、どこが馬鹿なのか指摘したらどうだ？

お前はわかっとらん。というだけなら、
ダメ上司でもいえるからさ。

>>323
あなたも指令パルスで制御するのは、ステッピングモータだけだと主張する290と同類ですか？

いや290そのものじゃないのか？

>>290＝323？は適職とか考えた方がいいぞ。
お前みたいなトンデモ・アマグラマーでも活躍できるフィールドがあるかもしれん。

駐車監視員とかどう？
結構旬だよ！

普通こういうプログラムは、複数で作るものだと思うが。
通常制御、例外制御、UIぐらいに分けるか。
通常制御のチームは何階から何階まで行けという命令が来たら、
何人乗っていてもズレなく快適に動作させるプログラムを作ればよい。
モーターがおかしいとかワイヤーが切れたとかは例外制御の仕事。
エレベーターが複数あって、最適に動かすには…はまた別のチームだ。

UIを分けるのは別にいいが、
通常制御と例外制御はわけるな。
余計バグが出る。

>>322
俺なら漢数字しか認めないね。

（移動制御）
・ボタンが押されたら該当階に移動する
・該当階到着の何秒か前の地点だったら急停止するとヤバいので通過
・該当階についたら乗降制御を始める
（乗降制御）
・開けてよい場所だったらドアを開ける
・開ボタンでドアを開けた状態を継続
・１０秒経ったら自動的にドアを閉める
・５秒以上経過して閉ボタンが押されていたらドアを閉める
・ドアが閉まっていてどこかの階のボタンが押されていたら移動制御に移る
・ドアが閉まっていてどこのボタンも押されてなかったら移動しない

しかし、これだけシーケンス制御がおかしいのを見逃すとは・・・
アホきわまりないなｗｗｗ

おまえら全員シンドラーエレベーターで死刑

>>332
バグ発見！

if(ドアが閉まっている && どこかの階のボタンが押されていいる) {
　　/* ここでドアを開く割り込み発生 */
　　移動する
} else {
　　移動しない
}

323がバカなのはオレでもわかるｗ

道具

使う

シンドラーエレベーター

ゆうしゃは死亡した・・・

死んだら教会で生き返らせてもらえばいいじゃない

そんなコストはかけられません

外で虫や獣を倒したらいくらでも金が湧いて出てくる世界では
どういうコスト概念が存在するんだろう。

>>340
ほぼ、金額∝時間、だな。

エレベーターのモーターは三相交流サーボモーター。
交流モーターにもサーボモーターにもパルスなんて概念は無い。
まず電気の基礎知識を身につけよう。
交流とはなんぞや
交流の電気を流すのに0と1のパルスを流せばいいと思ったら大間違い。
そもそも交流は0と1ではない。
交流なら知っているよ、コンセントの電気でしょと思っている君、
でも二本のプラグから出ている交流は二相交流なんだな。
三相交流モーターはR、S、Tの三相で動くんだ。
三つの波があるんだよ。
普通のモーターは電気を流すと回るだけ。
指定位置で止めることができる力のあるモーターが三相交流サーボモーターなんだよ。
ま、アプリのプログラムの知識をかじっていたらエレベーターのプログラムも語れると勘違い坊やに言っても無駄か。

>>342
別にモーターの原理は知らなくてもプログラムは書けますよ。
入力電圧を加えれば、力が発生するブラックボックスとして扱ってもなんら問題はない。
プログラム書く側にすれば、モーターが直流電源で動いていようが、
超伝導を利用した磁気的なシステムであろうが、
さらには反重力を利用したシステムであっても関係ない。
制御理論の知識は必須だが。

ほほ〜　君は三相交流サーボモーターにどう電圧を加えれば指定の場所にエレベーターを止められるか知っているしプログラムも書けるということか。
それはすばらしい。どうだ是非我が社に入社しないか？　シンドラーより>>343さんへ

>>343
ここにいるのは、そのブラックボックスの中身を書いてる人達なんじゃないかな。

組み込みやってる人の話は面白いけど、上位層やってる人間をアホの子みたいに
扱うのは止めて欲しいな。ま、実際アホに見えるんだろうけど、住んでる世界の
常識が違うだけなんだけどね。

>>344
簡単なモデルを設計してみたよ
　　　　　v　＿　　F　　＿＿＿　　　＿　　　　r
─→○→│f│─→│e^Lt│→│P│─┬→
　 - ↑　　￣￣　　　 ￣￣￣ 　　　￣　　 │
　 　│　　＿＿＿　　　　　＿　　　　　 　　│
　　 └─│f^-1│←─│K│←───-┘
　　　　　　￣￣￣　　　　　￣
v：動力源への入力
f：入力と出力の関数
f^-1：fの逆関数
e^Lt：遅延
F：動力源から発生される力
P：エレベータのモデル
r：エレベータの位置
K：コントローラー
モーターをブラックボックスとして扱うとはf、f^-1、e^Ltが分かっている状態。
これは非現実的なことではなくモーターの製造元に聞けば分かるというか、
モーター購入前に詳細な仕様書を入手するだろう。
でないとどのモーターを購入するかの比較ができないから。
Pはエレベーターの質量とか慣性の項でモーターとは関係ない。ならKは求まるね。

おつー。
一昨日、昨日と試験装置デバッグしてたので、これなかった。

フィードバックはうちはつかわねー。どうなるかわからんから。
んで、当然モータも電圧と回転数は非線形。
たぶん物を作る装置でないから、伝達関数とかはそんなに
問題にならんのでは？
俺が作れって言われたら、ＰＣなら実際に重量かけて、
キャリブレーションするけど、シーケンサでは無理だな。
やっぱなにがしかの重量と制御の関連を見かけ上関数に
置き換えて誤魔化すしかないのか。

３層交流は、シーケンサ側からは電圧かければインバータが
ごにょごにょしてくれるけど、最適化しようとすると、どの周波数
で起動するかとかいろいろやりようがある。どこの電車か
忘れたけど、発射時に低い周波数からだんだん音があがってくる
電車があるよね。ピロリロリーとかいうやつ。
あれは日立の特許で、周波数を上げていって回転したところで
止めるんだと。高速エレベータはやってるかもしれないけど、
とりあえずここではインバータてかモータコントローラを素直に
使っていいんでないかな。

３層交流
３相交流
？

んで
>>332
移動するってのが面倒だと思うよ。
>>285
のいうとおりだと思うので、各階のドア開閉装置と
籠が正しい位置でかみ合った場合にのみドアが開閉できる。
まずは
１）正しい位置というのをどうやって検出するのか。
２）三相交流モータでピタリと止める技術。
　もちろん行き過ぎもあるだろうから、オーバーシュート対策も必要。
　減速アルゴリズムも色々あったと思うがここらへんがノウハウなんだろうな。
３）インターロックした後のドア開閉メカニズム。
　機械的にロックするんだろうか？ブレーキをＯＮにはするんだよね。
　ここでブレーキは壊れないって前提で作ってたのかなぁ。
　とにかく中側ドアと外側ドアをリンクさせて開ける。中側だけも
　無理矢理あけることができるので、外、中違う制御になるね。

>>323
俺が知ってる一番強いステッピングモータでは人間持ち上げられると
思うけど多分２階に運ぶのに２分はかかるなぁ。

全てがブラックボックスじゃいくらなんでもプログラムは作れないだろ。
「４階に行って止める」の一言でもどうやってプログラムを実現するのか想像がつかないんだから。
想像力をふくらませるとかトンチンカンなこというなら板違いだぜ。
全てをブラックボックスにするのはいいが黙っていられず知ったかぶりをしてパルス出すとかどうとかトンチンカンなことを平気でいう。
パルス出すのはステッピングモーターで、パルスの数だけ決まった角度が回転する。
これは小さい力しか出せず高速回転に向かないからエレベーターのような大きな機械には全く使えない。
ステッピングモーターは動かすのが比較的簡単。
低速の回転ならパルスを出すだけでいいので誰でも作れる。
早く回そうとすると脱調といって回らなくなるのでそれを回避するために少しずつ回転を早くするプログラムが少し難しいぐらい。
あと、脱調チェックも必要。
エレベーターはサーボモーターだ。
さて、この制御方法は俺は知っているが(実際にエレベーター制御プログラム作っていたからな)
おまえらバカには教えてやらない。
一言いってやる。
知らないなら黙っていろ。
笑わせるな。
バカはウィンドウズのアプリケーションソフトでも作っていやがれ。
ウィンドウズアプリならスレ違いだぜ!!

エレベーター技術はもう３０年前位に確立しているのに｡
世の中があまりにもビジネス指向(金儲け)になりすぎ
つけを払うときになったのでは｡

ゲームプログラマーに作らせろよ。
短期間、安い賃金で、もっと凄いものつくるぜ。

エレベータでセーブと回復が出来るようになりそうだな

挟まれたら、とりあえず、リセットボタンを。

>>350
つまり、エレベーターの世界はまだモジュール化があまり進んでないって事ですかね？
それとも更に高度な事をするために直接触るようにしてるのか
それともリソースとかなのかな。

良く考えたら工場のラインとかも一品物だしそれで良いのかも・・・

>>355
恐らくそんなところだろうね。
漏れは精密機械系の制御をやっていたが、ステッピングモーターの制御はモードの指定とパルス数の指定だけだったね。
電流制御やパルスの周波数制御なんかは全部ドライバに任せていたからハード屋さんでも調整できたし。

>>342
だから「指令パルス」って言ってるじゃん
そのパルス信号を受け取ってモータを回すのはサーボドライバとかサーボ側ハードの仕事でしょ？
モータに直接DC3.3〜5V程度の電圧入れたって動くわけないのは勿論、大前提。
CPUの信号電圧で駆動云々を論議してるんじゃないんでしょうよ？
そんな事言ったら、ステッピングモータだって回らないしね。

ちなみに283じゃないから
悪しからず

>>350
この板さぁ、制御系のスレもあるわけよ
「俺だけ制御系知ってます。おまえらどうせ知らないクセに」みたいな発言は痛いよw

バカが暴れてるな。
「指令パルス」の意味が理解できないんだろうな。
パルス＝ステッピングと思考がショートしちゃってかわいそう。

>>359
しかもまったく知らないんだからな。痛いとか通り越してる。

おいおい、まだヤツで遊んでるのか？
どんだけ大人気だよw

>>357
だよな。

バカはCPUおよびロジック部からどんな信号が出てるか言ってみ！
ちなみに救いようのないバカのレス番
↓
>>290 = >>323 = >>342 = >>344 = >>350

こういうもんの制御指令はパルスじゃなくてレベルでやるんじゃね？
間違えたんなら間違えた、詳しくないなら詳しくないって言えばいいのに
なぜ意固地になってるのかわからん。

別に電圧制御でもいいけど、ここはパルス制御を知らないバカを虐める会ですから・・・。
というかCPUから電気レベルでどのように信号が伝わるか分かってないバカを虐める会とも言えるが。

>>363
パルス列入力のサーボドライバーとか珍しくない

>>363
おまえ臭うな

>>350
いや、でも、やっぱりおかしいんだよ。

詳細がどんな制御になっていようと
上昇、下降、ドアの開閉
のステータス自体を遷移させることはその仕組みは絶対に関係ないんだ。

あるとすればそれはプログラムの作り自体に欠陥がある。
これは絶対だ。

何度もいうけど仕組みがどうなっていようと大まかなステータス遷移自体にバグがあるのはおかしい。
制御もアプリも関係ないんだ。
プログラムがプログラムである限りこのバグは制御もアプリも関係ない。

ザ・タワーのアルゴリズムですよ

何でパルスにするんだ？
そのままIOに値を出せばいいだろ

値を貰って動くモーターなんて無い。素人が。
U,V,Wとか分かるか？

ULSI、VLSI、WLSI

値をパルスに変換するハード入れろや

パルスで動くのはステッピングモーターだと言っているだろうが、ヴォケがっ！

とすると>>370が知ったかなんだな

>>367が正しいと思います。
パルス云々はハードウェア層の話。
アプリ屋がハードウェア層に疎いのは当然で攻めることでもない。

アプリケーション層で禁止事項をチェックしつつ、
ハードウェア層でも禁止事項が該当する要求は拒否するようにするべきだと思う。

エレベータみたいなものはホストマシンでエミュレーションするだろうから、
これらの層は分離されているはず。

>>373
本人さんじゃないから、遊んであげれないよ

>>376
ばれたか。

ブラックボックスと遣り取りする仕様さえ決めれば、
全てブラックボックス化しても問題無いと思うんだけどな。
つか、普通そういう考えで設計するだろ。

プログラムは外注なの？

>>389
外注以外にも、ハードウェアの設計変更に強くなるというメリットも有る。
モーターの製造元が倒産しちゃいましたーとか、
例えば最大100kgでも1tでも回数制御のプログラムは流用できるとか。

デメリットは部品や構成要素が多くなる事による物理的なものと検証のコストアップ

>>352
だが断る(キッパリ)！
ゲームがバグっても人は死なないが、組み込み系でバグると本当に死人がでることもあるからな。

>>381
ドミネーター乙

どうして、こーゆー構造化なやつが来るかなー。
シーケンサには関数も、再帰もスタックもないぞ。
モジュールはキーエンスとかなら多少できるのかな？
古いのにできるわけない。スイッチの固まりと思ってくれ。
スイッチにモジュールがあるか？

さて、モータの制御は電圧とパルスで行うのもあるが、
普通はパルス発生装置使うよ。パルスを発生させんの面倒でしょ。
DUTYとかもあるし。モータの回転に従って、ロータリエンコーダを
フィードバックにつかうんだね。
でも、ロータリーエンコーダが何回転したか自力で覚えないと
いけないし、やはり前段にサーボアンプないと非常に面倒でしょ。
だいぶん昔にＰＷＭ出したこともあったけど最近はやらねー。
０〜１０ＶでＭＡＸ１万回転とか。

んで、>>367
まったくその通りで論理的にはちゃんとできてたんだろうな。
ただアナログは必ず期待を裏切るのだよ。
その組み合わせができてなかったと思われ。
おそらくは位置決めをする近接センサがすりぬけたことと、
報道にあったようにブレーキに故障があったという２つの不運
が重なったケースをテストしてなかったんでしょうね。
さて、ここの諸君は例外ケースの組み合わせは全部みてるのかな〜ｗ

>>383
あなたにお伺いしたい。

>パルス出すのはステッピングモーターだけだ。
この発言について、どう思います？
ﾋﾞｼｯと言ってやって

>>383
君の言う例外とは「想定外」の事かな？
ところで、なんで急にPWM語りだしたの？
今時のCPUならPWMなんてITU使えば特に苦労しないよね。

>>383
>まったくその通りで論理的にはちゃんとできてたんだろうな。
>ただアナログは必ず期待を裏切るのだよ。
>その組み合わせができてなかったと思われ。
>おそらくは位置決めをする近接センサがすりぬけたことと、
>報道にあったようにブレーキに故障があったという２つの不運
>が重なったケースをテストしてなかったんでしょうね。
>さて、ここの諸君は例外ケースの組み合わせは全部みてるのかな〜ｗ
いや、だから、わっかんねぇ奴多いな。
関係ねーじゃん。
アナログが期待を裏切った結果、ああ、やって大枠のステータスの遷移までバグっちゃうの？
違うでしょ。これが全然別の問題であることがなんでわからないの？

センサがどうとか関係ないから。

このスレ見て分かった事が一つある

シンドラーじゃなくても、殺人エレベーターを作る可能性がある奴がいる

物理的な構造化を言ってるのに関数も再帰もスタックも関係ないだろ。

>>388
つヒント：誰もそんなこと言ってないｗ

>>389
>>383

>>290 = >>323 = >>342 = >>344 = >>350
↑
こいつが一番救いようがない。

>>390
389は多分
383の「シーケンサには関数も、再帰もスタックもないぞ」
の発言に対し、「突然どっからそんな話が出てきた？」
という指摘をしたものと思われ

>>383
知ってるボキャブラリ並べて自分を大きく見せようとする
痛い子を演じるのが流行ってる訳？

ときにインバータってどうコントロールしてるんでつか？

まあ、いろいろ言い様はあると思うけど、アナログ一回やってみたら
いいと思うよ。ただ、俺も使ってるだけなので三相交流に限って言えば、>>311
とかの方が詳しいと思われ。以下自分なりの理解。

三相に電圧の位相を変化させてかけると回転する。この電圧変化をきちんと
作るのは大変なので、ＰＷＭという方法である電圧のＯＮ／ＯＦＦの
比率を変えて擬似的に電圧変化とさせるのがパルスで出力させる
ということだと思ってる。１０ＶでＤＵＴＹ５０％のパルスをだせば、５Ｖ
相当ということだね。パルスを発生させるだけで、モータの制御ができる
のでお手軽ってことだ。力率とか理解してませんｗ
インバータは効率がいいってことは知ってる。
ということで、モータ自体はあくまで交流で動作するが、パルスで制御する
方法もあるよってことでいいかな？


ソフトの側からはＣＷ，ＣＣＷを設定して電圧かけると回る。ステッピング
モータのパルスとは違い、ロータリーエンコーダの有無は制御とは動作
と関係ないので、どれくらいの位置を移動したかは制御できない。
回転角を読み取る必要がある場合にはロータリエンコーダを別途使う。

速度はロータリーエンコーダからのパルスを積分すれば求まる。位置は
リミットスイッチや近接センサで０点リセットしておいてからエンコーダの
パルス積分するかな。これより電圧をコントロールして加速、低速、減速
のカーブを自力で作る。こういうのもやってくれるインバータも普通にある
と思う。

自分の力のなさだと思うけど、毎度モータ回すだけで結構苦労したりするかな。

下がってよいぞ

最高時数十キロにも達することがあって都度重量が変わる物体を数ミリオーダーの
精度で狙ったポイントに静止させるって、考えてみたら凄いことだね。
ひょっとして無人ロケットの火星着陸並にシビアなコントロールが要求される世界なんじゃ。

パルス
http://dic.yahoo.co.jp/bin/dsearch?index=15132500&p=%A5%D1%A5%EB%A5%B9&dtype=0&stype=1&dname=0na&pagenum=1

独り言言ってる人いない？

あ、それ俺！

このスレの３／４位は独り言っぽいぞ。


おれもな〜

>>395
だめだ・・・制御系には足を踏み入れるなよ！

取り合えず、過ちや無知を認めず自分の主張ばっかりする奴は
制御系は向かないわな（第２の殺人エレベータを作りかねない）

駐車監視員で頂点目指しなさいって事で

騒いでるのは学生だろ
まともな社会人だったら違う分野の事を大して知らずして
んな主張ばっかするわけない

学生だったらせめてもの救いだな
まだ、道を誤っていない訳だから

>395
3相の電位を図で書いてみればいいんじゃね？

>397
距離だけ正確に出せればいいような。

ま、どこにもシンドラーの芽はあるってことだな。

>>403-405
だな。
モーターのことも指令パルスのことも知らなくてもやっていける分野（新聞販売員など）はあるのだから・・・。

職業差別の意識があってもエレベーターは動かせると
適材適所ということだね

なんで新聞販売員なんだろうなｗｗｗ

自分が説明下手糞なのを棚にあげて、
「組み込みやってみたら？」とかいってるような技術者なんて最下層レベル。
しかも、絶対組み込み云々の問題じゃねぇよ。
だって明らかに大枠のステータス遷移がおかしいのなんて組み込み云々の問題じゃねーじゃんｗ
問題の切り分けもできないくせに組み込み理由にして変な理由でっちあげてんじゃねーよ。

パルス制御しらないって人間がいるってマジかよ？

人間ｗｗｗ

まぁ、他業界だと常識も違うしなー

完全にハードよりなエレベータみたいな組み込みは正直解らん。
POSレジや自販機レベルなら解るけど。

>>414
自販機は普通にＣ言語で制御してた。
コンビニのレジの画面はFlashで作ったなｗ

>>415
それは店員に見せる画面じゃなくて客に見せる方の画面じゃないのか?

>>416
いや、逆も普通にFlashだよ。
Flashの意味まったくないけどｗ

>>412
俺のような、通信機器一本槍だと概念は理解できても
実際にどう使うのかは分からん

ま、報道されてる障害を聞く限りじゃ>>367の言うとおり
エレベータ事故の件とパルス制御云々は全く関係ないだろう
というのは推測できるけど

「分野が違うから詳しくない」って奴は特に問題はないが

>>290 = >>323 = >>342 = >>344 = >>350 みたいな奴は大問題。

いまテレビ東京で点検システムの検証してる

このスレ見て、
わかっている奴でも
この程度だとわかったので、
エレベータで人が死ぬのも
納得できた。

自称「わかっている奴」は実は解ってないから納得するな

シンデラー社員必死だなｗ

>>421
見方が逆だ
解ったつもりになってる奴が人を殺す

「絶対安全です」と言い切るエレベータの方が乗るの怖いよ

>>425
同意。自動車みたいにリコール制度があればいいのに。

アプリ系と組み込み系の意見の食い違いについて・・・。

エレベータでなくとも、パソコンを例にしても説明できると
思います。

パソコンのハードとソフトは、簡略化すると、
次のような層になっています。

・ハードウェア（ＦＤやＨＤＤ、ディスプレイなど）
・BIOS（説明は→http://e-words.jp/w/BIOS.html）
・OSのHAL（説明は→http://e-words.jp/w/HAL.html）
・アプリケーションソフト

BIOSやHALは、ハードウェアを直接たたくプログラム群です。
これがないと、極端な話、ＨＤＤの電源を入れるところから、
ヘッドをシークさせて適切な箇所を読み取る、なんていうレベルまで
自分でプログラムすることになってしまいます。

（他にも、Windows以前、ディスプレイにドットを描画するだけでも、
アセンブラやＣ言語のポインタを使って、特定のメモリアドレスに
ビットを書き込まないといけなかった・・・）

そこで、各ハードウェアに共通規格を持たせ、それを制御する
汎用プログラムをBIOSやHAL（OS）として用意しているわけです。

>>427
それが大枠のステータス遷移にどう影響するのか説明してくれませんか？

普通、アプリ系の人は、OSのAPIなどを通じて、HALにアクセス
することで間接的にハードにアクセスします。
ここら辺を、どなたかは「ブラックボックス」と言っているのでしょう。

確かに、HALはハードをブラックボックス化することが目的ですので、
正しいですよね。

一方、組み込み系の人たちは、このBIOSやHALのレベルを含めて
（あるいは、ここだけを）プログラミングするわけです。

既に話にでていますが、組み込み系では、OSを使わない場合が
多いです。ということは、このBIOSやHALのレベルから、自分たちで
コーディングすることになるわけです。

（Windows以前のDOS時代には、アプリメーカーもDOSではなく、
自前のOSを作ったりしていたので、現在ほど組み込み系とアプリ系
の意見が食い違うこともなかったですよね・・・）

ここで、エレベータに話を戻すと、組み込み系の人はBIOSやHALの
レベルである、サーボモータの制御プログラムなんていう話になります。

一方、アプリ系の人は、このレベルを「ブラックボックス」として
考えるので、エレベータかごのステート問題では？という話になります。

こうして、意見がいつまでもかみ合わないのではないでしょうか？

ちなみに、恐らく、エレベータのプログラムといった場合、
実際にはこの両方のレベルを自社開発するのではないでしょうか？

また、BIOSレベルになると、プログラムが書き換え可能ではなく、
ROM（一度書き込むと内容が消えないメモリ：CD-Rのようなイメージ？）
に焼き込んだり、専用ハード化、専用LSI化したりもするので、
プログラム交換＝基盤交換、になることもあります。

こういった感じで、ハードとソフトが多分に絡み合っていて、
その区分けも設計次第なので、エレベータといっても、設計が
分からない限りは、プログラムがどうのこうのという議論も
不毛な気がします。

それをいっちゃあおしめぇよ

>>427,429-430
いや、だから、それって組み込みの手続きが面倒なだけの話じゃん。
ハードとソフトと絡みあってて面倒ってただそれだけ。
（しかも、それだってわざわざそんな作りにすること自体がはっきりいって無駄なだけ、
やっぱり、十分なＣＰＵ、メモリを積んでそれなりの制御ができるようにしたほうがこういった事故を減らせるので
あれば、ショボイハードで無駄に頑張るのは組み込み屋のただのエゴ。だと俺は思ってる。）

実際のプログラムの大枠のステータス遷移に影響をおよぼす理由までいきついてないんだけど。

> 実際のプログラムの大枠のステータス遷移に影響をおよぼす理由までいきついてないんだけど。

ステータス遷移だけの問題だと考えるためには、「ブラックボックス」部分が
正常だという前提が必要です。

アプリ系の人は、「ブラックボックス」部分に間違いがあるとは
考えない傾向が強いと思います。（例えば、パソコンの
電気・電子回路ですら、タイミングによって不具合が発生する可能性がある）

一方、組み込み系の人は、「ブラックボックス」部分にどうしても意識が
向いてしまう傾向が強いのではないかと。

最初に注目する部分が違っているわけですが、実際のところ、
どちらに問題があるのか、それとも両方なのか、それを
外部から見て取るのは難しいのではないか、と思います。

今回のエレベータにしても、ステート問題の扱い方がまずかった可能性もあれば、
前提としての「ブラックボックス」が想定外の動作をした可能性もある、
と考えられないでしょうか？

> やっぱり、十分なＣＰＵ、メモリを積んでそれなりの制御ができるようにしたほうが

エレベータに関しては、この部分は確かにそうとも思います。
私たちが知らない制約が無ければ、ですが・・・。
例えば、携帯のように、サイズや価格による制約がある場合は、
選択肢は限られてきますよね。

それと、汎用ＯＳには、エレベータのハードを制御するような
モジュールは無いでしょうから、汎用ＯＳを使っても仕方がない、
という判断にはなるかと思います。

ただし、例えば、管理画面を豪華なＧＵＩにしたい、といった部分には、
汎用ＯＳが選択肢に入ってくるのではないでしょうか。

>>433
>前提としての「ブラックボックス」が想定外の動作をした可能性もある、
>と考えられないでしょうか？
はぁ？なにいってんの？
ブラックボックスとしてみられるっていってるのはお前がハードの仕組みに異常にこだわるから
「そんなの関係ねぇよ」ってのを説明するためにハードに依存する部分をそう表現しただけだろ。
例えば、今の話題でブラックボックスと表現する
bool checkOpenDoor()
みたいな関数をつくったとしてこれの中身の細かいところは組み込み系特有の複雑さは
あるけどこの関数自体がおかしい理由が組み込み系だからってことにはならないよね？

＞アプリ系の人は、「ブラックボックス」部分に間違いがあるとは
＞考えない傾向が強いと思います。
おいおいおいおいおいおいおいおい勝手に決めるな。
アプリ屋とて基盤部分を妄信してるわけないよ。
だから仕事に使う環境には、高い金を払って十分なサポートが受けられるものや
フリー・オープンソースでも実績のあるものを選んでいる。

そんなこと言ったら組み込み屋だって「回路や電気系統は間違いなく動作する」
という前提でプログラム作ってるだろが！
それはブラックボックスちゃうんかい！

>430
各社の特許や権利問題考えたらむしろそれが当然と思える。
でもそのレベルの組み込みって、少なくともマイコン制御な家電以上の代物だよ。

>432
＞十分なＣＰＵ、メモリを積んでそれなりの制御ができるように
そのほうが難しいと思うけどね。ハードで組めるものをソフトで置き換えようとしても実は上手くいかない。
多分バグが出やすくなってデバッグが面倒になったり、(もしかすると)事故が増えると思う。
フールプルーフもハード異常の対策もハード的にやったほうが良い部分だろうし。

エレベーターだったらソフトはほぼ補助的なもので、それこそロジックで組めそうな気がするくらい。

>433
ハードを手抜きしてソフトで対応、ってのが一番まずいと思う。
「ブラックボックス｣的な考え方は、結局設計を分離できるためで、アプリを組む場合は
推奨すべきことなんだろうけど、組み込みだと全く逆で、むしろブラックボックスが無いほうがいいくらい。

>434
UI部分に、というならいいのだが、あくまでそれはそれ以外の部分を完全に
信頼できる｢ブラックボックス｣としてみなせるか?という問題がある。
もし、そのUI部分に問題があって異常動作をしたらどうするの?
金融・証券関係には多いけど、｢完了｣するか｢初期状態に戻す｣かのいずれかしか許されないシステムもあるんだし。

OSを使うのは開発期間の短縮や物理層の違いを吸収する意味もあるね
でもエラー処理くらいはしましょう。文化祭に出展するんじゃないんだから

>>437
>多分バグが出やすくなってデバッグが面倒になったり、(もしかすると)事故が増えると思う。
多分？要はやったことないんでしょ。
わかるよ。
組み込み系の奴等ってのは自分の知ってる世界から絶対にでようとしない。
だいたい、こんな処理難しいなんていってる時点で事故が増えるも糞もないだろ。

> bool checkOpenDoor()
> みたいな関数をつくったとしてこれの中身の細かいところは組み込み系特有の複雑さは
> ある

ので、ステート問題を考えるアプリ系寄りの層と、
ハードを制御する組み込み系寄りの層
（「ブラックボックス」と言っていたモーター制御などの部分）との、
どちらにも間違いのある可能性があるのではないか？　ということです。

えー、別に私は、どちらかを批判したり、擁護したりしているわけではなく、
両方の可能性を考えればいいわけで、それをどちらかに絞ることが、
今の判断材料では難しいのでは？　ってことが言いたかっただけです。

なんか、アプリ系寄りの人と、組み込み系寄りの人ととで、意見が
変なところで対立していると感じたもので・・・。

それぞれの着眼点が、違っているだけなので、対立する必要はないのでは？
と言いたかっただけです。

どうして民族対立みたいな流れになってしまうんだ……

>>440
だから、問題は単純だろ。
この例なら、
checkOpenDoor関数が正常に動くかどうかだけだ。
別にハードの仕組みなんて関係ねーんだよ。

> おいおいおいおいおいおいおいおい勝手に決めるな。
> アプリ屋とて基盤部分を妄信してるわけないよ。

勝手に決めたのは謝りますが、あくまで「傾向」があるのでは？と。
特にWindows以降の若いアプリ・プログラマーの人は、ＡＰＩをたたくことは
知っていても、ＡＰＩから先のイメージを掴めていない人が多い
と感じるので・・・。


> そんなこと言ったら組み込み屋だって「回路や電気系統は間違いなく動作する」
> という前提でプログラム作ってるだろが！

という対立姿勢にならなくても、よろしいのではないかと、言いたいわけなんです・・・。

そもそも、アプリを作るのと、制御プログラムを作るのとは、
どこを「ブラックボックス」とし、どこに注力するかの違いだけで、
どちらもそれぞれに大変なところがあるわけで。

仲良くすればいいし、お互いの話を聞いたり、両方をやってみたらいいじゃん、
ってことです。

アプリの方の人が「それなりのOS使え」とか言うからでは？
漏れはアプリ屋だけど、おそらくエレベーターの制御なんてPCIやらDMAのコントローラの
動作と同程度にシンプルかつそうそう変更されない部分かつステートが少ない部分なわけで、
そういうのはソフトウェアで実装するよりはもっと低レベルな実装の方が向いているような気がする。

PCだって膨大な規模のHWロジックや、シンプルなOSすらないCPU＋ファームウェア＋HWでうごく部品を使いつつ、
必要な部分だけ大きなOS載せてソフトウェアを動かしてるわけで。

>>443
この問題でcheckOpenDoorやcheckCloseDoor関数が
正常に動作してるか否か以上の理由がなんかあるわけ？
馬鹿なの？
問題の切り分けもできないのによくプログラマなんてやってるね。君。

>>445
＞この問題でcheckOpenDoorやcheckCloseDoor関数が
＞正常に動作してるか否か以上の理由がなんかあるわけ？

その関数が間違ってたのか、それともハードが返す値が間違ってたのか、
それは不明なわけで・・・

切り分けが出来てないのは>>445だよ

ハードもソフトもブラックボックス化した方がいいよ。
システム構成が変わった場合はその部分だけ変えれば済むんだから。

>>446
ほい、でここを議論するにあたって組み込み系特有の話なんか欠片も出てこないのはわかったでしょ。
なんで複雑そうにいうの？回路の仕組みがどうとか全く関係ないじゃない。
結局はcheckOpenDoorやcheckCloseDoorが正常に動くか動かないか？
って単純な話じゃない。
ハードがどんな状況においても本当にハードがなるべき値を返すのかどうなのか？
テストやっていれば絶対に気が付くレベルだよね。

もう一度聞くけど、「これのどこが組み込みやってないとわからない話なんですか？」

>結局はcheckOpenDoorやcheckCloseDoorが正常に動くか動かないか？

日本語でよろしく

>>449
話の流れがわからないなら参加しないほうがいいよ。

たしかに組み込み系やってないとわからないって話じゃないな。
上の方のレスでモーターがどうだとか話してた人は一体何がいいたかったんだろう。

> テストやっていれば絶対に気が付くレベルだよね

ものすごい低い確率でしか発生しないような現象（エラー）もある、ってことです。

アプリの話に限定したとしても、例えば、マルチスレッドを利用している場合、
スレッド間の同期の不具合が、低い発生確率でしか発生せず、テストをすり抜ける
ことがよくありますよね？

少し前、どこかの銀行のＡＴＭも、起こりえないようなタイミングで、
2箇所の端末である操作がなされたことが原因で、システムダウンした
こともありました。

で、ハードウェアの制御系に関しても、そのやり方によっては、
マルチスレッドと同じような同期タイミングによる問題もありうる、
ということです。

だからこそ、「シンドラー社の説明では、この欠陥は同社の設定ミスで、
扉が閉まって０・２５秒以内に「開」のボタンを押すと、
扉が開くにもかかわらず、
扉が閉まってから０・５秒後に始まるモーターの起動が止まらず、
かごが動き出す。」
（http://www.asahi.com/national/update/0616/TKY200606160321.html）
なんてことになった”可能性も考えられるよね？”ということです。

（４５２続き）
それと同時に、ただ単に、状態遷移のアルゴリズムが
お粗末だった、という”可能性も考えられる”わけです。

これがどちらであるかは、もう少し情報がないと、
判断できないのではないでしょうか？

さらに補足です。

>>27のようなステートだとしても、

例えば、エレベータの「開」「閉」を調べるセンサーが、0.5秒ごとに割り込み通知によって、
ステートを管理するプログラム（マイコン）に通知するような設計になっていれば、
この問題が発生しますよね？

>>448
組み込み系ではハードとソフトの両方のデバッグが出来ないと行けないわけだよ。
熟練したプログラマーは回路図を読んでハード屋に間違いを指摘するような世界だ。
ソフトしか分からんガキは黙ってろ。

ちなみに、マイコンの「割り込み」については、
http://www.assoc.tron.org/jpn/seminar/chap1_1.html
が分かりやすいですよ。

上記ページは「パソコンOSと組込みOSの違い」というタイトルです。

ここに出没する自称・組み込み系、機械系、の奴はパルス指令すら知らないんだぞ。
そんな奴とウダウダ話してどうするよ。

>>452-455
アホ？
そんなの組み込み特有の問題じゃねーじゃん。

俺がいいたいのはなんで「ソフトしかわからん奴は黙ってろ」って話になるの？って聞いてるの。

>>459
そりゃあんた、ハードの知識だけで食ってるのがばれるのがいやなんだろ。

>>460
ホント、そうにしかみえない。
こんなんでバグってるレベルのくせにＯＳ入れたら余計バグるとか
違いもわからんくせに組み込みはアプリとは違うとか頭悪いこと言ってる。
現状がこのありさまでどの口からこんな頭の悪いこと言えるのか全く理解できない。

リアルタイムを要求するのにOSなんか入れた日にゃあ・・・

>>459-461はｼﾞｻｸｼﾞｴｰﾝ

>>462
すくなくともウィンドウズでもゲームは動いてますが？
こんなエレベーターのステータスの制御もままならないなら入れてみたらどうです？

言ってる意味がわからん
何でゲームの話が出てくるかな

>>465
リアルタイムで動いてんじゃん。

はぁ・・・

釣り防止のためにみんなコテハンにしないか？

リアルタイムとＯＳはなんの関係もないな。
別にお金に余裕があれば載せてもかまわない。

ほれ
http://tool.nifty.com/oyakudachi/webapp/dictionary/search?book3=3&word=%E3%83%AA%E3%82%A2%E3%83%AB%E3%82%BF%E3%82%A4%E3%83%A0&option=0&page=0

>>470
まあ、ＯＳはあるってことだよね。

>>471
ウィンドウズじゃないOSはな

>>471
http://www.atmarkit.co.jp/ad/fujitsu_pst/linux0406/linux.html

>>436
＞そんなこと言ったら組み込み屋だって「回路や電気系統は間違いなく動作する」
＞という前提でプログラム作ってるだろが！

命に関わるようなものは、少なくとも（外的要因etc.で）予想し得る誤動作は
起こり得るという前提で設計するもんだと思うが？

＞checkOpenDoorやcheckCloseDoorが正常に動くか動かないか？
まぁ、そう理解してもいいけど、何故正常に動かなかったのか？
を言ってるもんだと思ってた訳だが違うのか？

単純に考えても↓みたいな、ことがありうるよな
　1)H/Wの状態自体が０．５秒に1回しか更新されない
　2)０．５秒に1回しか読みに行っていない
　3)信号自体は割り込みで入るが特定の条件で待たされることがある
4)S/Wの状態遷移自体がバグッてる

でOS入れたところで2,3は、自作することになったドライバの問題になるから
OSの有り／無しは全く関係ない

>>473
linux載るならもうフツーにC言語でフツーに組めますな。

>>475
http://laughingsquid.com/2005/08/11/netbsd-toaster/

>>474
いや、俺は「アプリしか知らない奴は黙ってろよ」的な奴を論破したかっただけ。
今回の問題が全然関係無いことがわかればそれでいいｗ

linuxじゃなくてもC言語でフツーに組めます

>>463
大間違い。

>>475 はなぜlinux載ってないとC言語でフツーに組めないと？

>>480
OS前提の汎用ライブラリが使える／使えないの違いかと

自演じゃないならコテ付けてください

>>482
まずおまいが

>>482
面倒臭いので嫌です。

スレが荒れるのはシンドラーの陰謀です。

スレが荒れるのはいつものことです

>>436
>そんなこと言ったら組み込み屋だって「回路や電気系統は間違いなく動作する」
>という前提でプログラム作ってるだろが！
はぁ？。動かなかったらソフトとハードと両方疑わないとデバッグできないのが組み込み系だ。
馬鹿が。×「基盤」○「基板」だ恥ずかしいやつめ。

>>487
でも、仕組みとしては今回のはソフト側だけで十分発見できる内容だよね。
組み込み系特有のバグではないよ。

>>487
そこは基盤で良いんじゃねー？
ハードのこと言っているんじゃないだろ。

>>488
まさにその通り
彼にとって製品が正常に動くかどうかは2の次で
ドライバやOSのバグは、バグじゃないんだろ

あいかわらず、論点のずれた不毛な議論が続いているようですね・・・。

別に、アプリだろうが、組み込みだろうが、両方経験すればいいのではないでしょうか？

優劣をいくら競ったところで意味はなく、片方の観点からしか議論できないこと自体が問題です。

何で、自分を「アプリ系」とか「ソフト系」とかって制限し、
自分と異なる分野の人を攻撃する必要があるのでしょうか？

色々な分野を経験しつつ、自分の専門分野も磨いていけばいいわけで。

経験したことのない分野について学んだり、聞く姿勢すら持たず、
現在の自分の知識の範囲内だけで結論を出そうとしていては、
「井の中の蛙」になるだけですよ。

むしろ、エレベータに関するたいした情報も得られていないし、テストすらできない状態で、
「これが原因だ！」と結論付けようとする姿勢こそが、危険でしょう？

別分野の人を攻撃する必要はないけど、
わざわざこのスレのために両方経験する必要もないだろ。

>片方の観点からしか議論できないこと自体が問題です

全く其の通りだよ

片方の観点のみから議論ふっかける香具師が多いから
そいつらに対して他の観点もあるんだよと言ってあげてるだけ

そこへ「何で両方経験する必要があるんだ？」とか馬鹿が湧いているという話

おまえは半導体の製造から経験してこい

目くそ鼻くそ

>>494
経験してますが何か？

ブラックボックス化されてれば別に経験する必要無し

つまりブラックボックスの中身に問題があったらお手上げな訳です

まあ、ブラックボックスは直せないにしても、回避方法は探すでしょ。

>>491
でも、今回の問題は組み込み系特有のバグではないよね。
どうして、そういい加減なこというの？

ここで喧嘩してる奴らにはエレベーターは難しすぎるようだ :-)

上昇ロック解除の処理中に割り込みかかっただけなんじゃ。
なんでこんなにスレが伸びるんだ

この板にいる連中にとっては、このあたりがちょうどいいお題だったということだ。

>>502

っつーかそんな簡単なことでバグるんならもっと早く分かってただろうに

対策取らなかった方に問題ありあり

>>504
直したんだけど修正前のものに戻されちゃったんだよね。ここが問題

>>505
そこはやっぱり工場出荷時ボタンとしか思えねぇ。
一部の基板だけ新しくして、プログラム自体は工場出荷時状態にもどしたんちゃうんかと。
こうなるともう、どんな動きしてもおかしくないわけだし。
テストばっかり無駄（？）に多い制御系でここまでぶっとんでるのもよくわからん話ではあるしね。

ソフト修正につぐ修正で管理がめちゃくちゃになったのでは？
交換作業進めてる間に別の不具合発生し一から交換、さらに交換品に大問題があったので緊急で元に戻せ、とか。
ソフトの出来を考えるとバグは１個や２個じゃないだろ。

>>502

それは、この「割り込み」という概念が共有されていない
ことが原因なんだと思います。

>>497

そんなことを言っている人は、Joel Spolskyの記事を読むべきです。

The Law of Leaky Abstractions（漏れのある抽象化の法則）
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

日本語訳は、書籍「ジョエル・オン・ソフトウェア」２６章にあります。
http://www.amazon.co.jp/gp/product/4274066304/

シーケンサとかここで語るものでもないような・・・

ツンデレのプログラムリストはまだですか

>>511

if(対象の好感度<基準値){
　行動=突っかかる
}else{
　行動=甘える
}

こうでｓ(ry

>>512
なんかちがくね？

こうか？

if (愛情<羞恥心) {
　行動=突っかかる;
} else {
　行動=甘える;
}

ツンデレルーチン(デレ度)
{
　行動(デレ度);

　if(デレ度 > デレ杉)
　{
　　デレ度 -= そんなんじゃないんだから！;
　}
　else
　{
　　デレ度 += rand();
　}

　ツンデレルーチン(デレ度);
}

スタック領域が足りなくなって発狂するぞ？

サマーデイズに関するお詫び
ttp://www.0verflow.com/html/topic/060628_apology.html

こっちもバージョン管理怠慢か。
エロゲーメーカである以前にソフトウェア会社としてｱﾚですな。

50 ：オレオレ!オレだよ、名無しだよ!!：2006/06/22(木) 12:04:51 0
2.6GBの修正パッチA配布開始
↓
ダウンロード一斉開始
↓
寝ているうちに1.2GBの修正パッチB公開
↓
P2PユーザーはP2Pにて修正パッチGet開始
↓
このAとBの1GB以上の差はいったい何だろうか
↓
圧縮方法変えたからだって
↓
いやムービー削ったんだよ
↓
BはＡより音質悪いんよ
↓
↓
Aには同じファイルがダブってるだけだよ
↓
な、なんだって(AA略
↓
ホントだｗパッチA確認したらハッシュ比較して同じファイルがダブってた
↓
　　 　　　　　/つ_∧
　　/つ_,∧ 〈（；ﾟдﾟ）
　　|（；ﾟдﾟ） ヽ ⊂ニ) まじっすか！ 　　　　←今ココ
　　ヽ__と/￣￣￣/ |
　 ￣＼/＿＿＿/￣￣

死んどらーにまた閉じ込められたとニュースが流れているが……
なんで急に頻発してるの？ソニータイマーみたいなもの？
それとも、普段から事故ってたのに今まで公表されて無かっただけ？

>それとも、普段から事故ってたのに今まで公表されて無かっただけ？
前から異常動作はあったらしいじゃん。
つーか、大事故って小さな事故が積み重なって起こる。
小さな事故はささいなミスが積み重なって起こる。みたいな法則ってなかったけ。
社長がTVで「殺人エレベータ作ってたことになるじゃないですか」って認めてたな。

うちのビルみたらエレベータによってメーカー違ってたな。リスク分散か。

>>521
１：２９：３００の法則だな

>522
株とかとは違って一つ事故が起こったらもう致命的なわけだから、リスクは増えてる気がする

>>524
お前、リスク分散の意味わかってる？
この場合、A社のエレベータが事故って原因が判明するまでは
A社のエレベータは全面使用禁止ってことになってもB社、C社の
エレベータは今まで通り使えるんだよ。

落ち着いてクスリ分散しとけ

おクスリください

つ● 正露丸

>>520
三菱の自動車が燃えたとか、電車がオーバーランしたのような物。

マスコミがネタになるからバンバン報道してるだけ元からこんなもんだと思ってる。

い…　　いまどきのエレベータって状態遷移するのにいちいちスレッド作ってんですか？
新規スレッド作ってる時点で状態が増えると思うが。
前のスレッドちゃんと消えなかったらどうすんの？

糞スレ立てんなｳﾞｫｹ　とかでも言うのかなぁ？

Ｊａｖａプログラマとシーケンサ使いは
朝鮮人と日本国民程にも理解しあえない件について。

>>531
実際にはソフトウェア的にエミュレートされているものの根本の思想は
マシン語よりも低レベルだからなぁ＞シーケンサ