DAブラックホール

DAブラックホールで連続解析（シーケンサーやインクルード）を前日からまわして、結果を翌日に見よう、という運用はよくある。
だけど、翌日の朝 開いてみたら、昨夜9時ぐらいにエラー停止して、1割ぐらいしか解析終わってなくてアタマをかかえてしまうことがある。

「なんでエラーなんだよ！」と。

でも、これね。

エラーが起きたときはちゃんと停止させないと、解析事故（課金）が 恐い。
仮に課金事故でなくても、エラー停止する以上は 回線かTAに瞬間的にでも「問題」が発生したということである。そのまま解析を続行したとしても「取得したデータの信頼性が損なわれているおそれ」があるんだよね。
そういったこともあって、エラーについては「発生させないセッティング」が第一であることには変わりない。（エラーに至った機序についてはイベントログにも吐き出されているので、読める人はぜひ読んだほうがいい）

とはいえ、切断時間を切り詰め ATコマンドも工夫してカリカリにチューニングしている環境だと、1/10,000の程度のTAのエラーは スルーしてほしいこともある。

そういうとき、リスクや細かい背景は承知の上でなら、解析中に発生するエラーメッセージを表示させない方法はある。

解析する電話番号に 6101 を入れて、その下のDAブラックホールのエンブレムをクリックする。

すると Yes/Noダイアログが表示される。
エラーメッセージを非表示にする場合は、[はい(Y)]を選択する。

この操作によって、解析で発生するWarning/Nortice/Information レベルのエラーメッセージは表示されなくなる。（表示されないというだけで 問題そのものは存在している点には留意）

一方 CriticalやEmergencyレベルのエラーメッセージは 引き続き表示される。
つまりDAブラックホールが掌握しているレベルのエラーは表示しなくなるけれど、OSが表示するエラー（データベース損傷など）は引き続き表示される、という理解を持ってもらえるといい。

この操作は「通常の解析」（連続解析を含む）のエラーメッセージを対象としており、マルチタップや他の機能のエラーメッセージには影響しない。
もしマルチタップによって発生するエラーメッセージも非表示にする場合は「6102」で同様の操作を行う。

いずれも本来はユーザーサポートから指示があった場合に限って使ってほしい機能ではあるので、使用する場合はある程度の覚悟をもって行ってほしい。

---

なお、元に戻す方法は、

設定(P)→出荷時の設定に戻す

である。

DAブラックホール1.8は

1.7の時とは異なり、1.8の企画は2014年にすでに決まっていた。
すなわち、先述の「ひとつめの失敗」によって、マルチエンジンの実装がなされなかったからだ。

ひとつのDAブラックホールで複数の解析エンジンを同時に動かすというのは、

• IP網用では2003年のDAブラックホール SIP2.0 （8チャネル同時処理）
• ISDN用では2005年のDAブラックホール1.4（16B同時処理）

において、いったんそれぞれ 実用化しているが、パッケージとしての販売には至っていない。
まず、IP網用はCPUへの負荷が非常に高く、当時のXeonマシンを要求するありさまだった。しかも、いまほどIP網は一般的ではなく、0AB-Jがやっと認可されたぐらいの頃だったので需要が薄かった。ま、そもそもコンセプト品として たいして売る気がなく作ったものであったから、こちらはDA電研の「ドメインレーダー」で使用することになる。これがのちに、あることがきっかけで KONDERU-NDAとして再転用されることになるわけだが、それはまた別の機会に述べる。

他方、ISDN用は、当時 私が顧問をしていた ホワイトなキャリアから発注を受け製造したものであったが、あまりに性能重視で作った結果、1システムでロッカー2個分の巨体になったこともあって最終的にはキャンセルになった。
（このため1.4は欠番になってしまうことになる。）

かように、高負荷になりやすい解析エンジンを、ひとつのPCで同時に動かすことは、様々な困難を伴う。
CPU性能が上がったいまなら、15年前と違って、いま少し容易なのではないかと考える向きもあろうが、そうは単純じゃない。
DAブラックホールの負荷は、主に「データベース」（分析と記録・すなわち読み込みと書き込み）が発生させているものであり、CPU性能が上がれば、負荷が下がるのではなく「データベース処理が速くなる」という方向でリソースを消費する。

そのため、2つ以上の解析処理を同時に行えば、現在でもきっちり100%の瞬間負荷がかかる。こういった状況で、多数の解析エンジンを同時に動かす場合は、解析するPCとデータベースのPCを分け、「負荷分散」を行う必要が出てくるかもしれない。

つまり、DAブラックホールから、データベースを切り離そう、という魂胆である。
DAブラックホール1.7で実装した「外部データ連結」は、その布石である。

1.8系では まったく新しい解析エンジンを用いており、他にも これまで見送られていた機能が実装されることになっている。いわばDAブラックホール1.ｘ系統の「総仕上げ」として位置付けられているのが1.8系であり、これが最後の1.x系統になる。

（ 「1.7とはなんだったのか」- おしまい）

※DAブラックホール1.8は2018年4月10月に発売見込み
2017年4月以降に1.7を購入した方には、1.8に対する優待または無償アップグレード特典が付与される予定

ドライバの不具合に悩む

ふたつ目の大きな問題は、リリース後に表面化した。

特定メーカーのdocomo端末を用いたときに、DAブラックホールが端末に接続できないケースが報告された。

COMポートは認識しているが、接続だけができない（≒初期化もできない）という謎現象である。
ただし問題が生じた端末でも、Bluetooth対応機種でBluetooth接続を行えば、この現象は発生しない。
問題は、きまって「USBケーブル接続」のときに起きていた。
つまり端末の問題ではなく、ドライバの問題であることが示唆されていた。

報告の数が 少しずつそろってくると、その現象は64bitOS上に限り発生していることがわかった。また特定メーカーの特定期間に販売された端末のUSBドライバだけで起きていることもわかってきた。

やがて、原因がわかった。
その携帯端末の64bit用USBドライバは WOW64（32bitエミュレーター）への対応が不完全だったため、32bit側の「MSCommコントロール」でエラーが生じ、ポートを開くことができないでいたことがわかった。
なお同メーカーの32bit用USBドライバには、この問題はなかった。

ドライバの不具合ではあるが、こちらも端末の検証用PCが「Windows7/32bit」であったことで、事前にこの問題を把握することができなかったのは、私のミスである。

コントロールの内製（自作）にふみ切る

不具合である以上、この問題を本質的に解決するなら、メーカーにドライバを改修してもらうのが筋である。
が、それを待ってる時間はないし、その当時 かなりゴタゴタしてるメーカーだったので、あまり期待はできかなかった。
またWin32APIを経由してファイルストリームでシリアルポートを制御する方法をプログラミングすれば、エラーによる門前払いを防ぐことができることも実験の結果わかった。

そこで おもいきって MSCommと互換性のある「DACommコントロール」を作成し実装することにした。

VB6.0でできるの？と思う向きもあるかもしれないが、時間はかかるものの、人間ワザの範囲だった。（いや、ほんとうのこと言うと、結構たのしかった）

なんというか、この20年・自分が使ってきたコントロールが どういった理由でそういう実装になっていたか、よくわかった。

そうこうして、次のようにクラスを再構成した。

DAブラックホール1.7の場合、デフォルトであれば、MSComm が選択されるが、通信デバイスの設定の「汎用コントロール」のチェックをはずすと DAComm になる。

この問題では、苦労もし、悩まされもしたが、有意義な時間を過ごさせてもらったような気がする実装につながった。

（つづく）

ひとつめの失敗

DAブラックホール1.7に実装するキモのひとつに「ダブルタップ」があった。

これは2つの回線（あるいはキャリア）を使って、同時にひとつの番号を解析する機能である。
この機能があれば、一挙動で「キャリア判定」のアタリをつけられ時間短縮になるほか、同一の回線に同時に発呼することで、たとえば iナンバーやダイヤルインで割り当てられている回線数を見つけることができる。
DA電研で使用している回線解析システム「KONDERU-NDA」に実装済みで、実績もあった。

2014年1月頃、いよいよこれを1.7に実装したところ、
「なぜか 2回線のうち 1回線ずつ解析（発呼）が実施される」
という事態に直面した。
A、Bの2回線で同時に解析処理を実行しているのに、Aの解析が終わってから Bの解析がはじまる、という具合だった。

調べてみると、シリアルポートを制御するMSCommコントロール→Win32通信API→ドライバの経路のどこかで、片方の処理に待機がかけられていた。
そのため片方の解析が進行し、終了すると、待機していた側の動作が再開するという状態だった。

VB6.0特有の問題

原因は、以下の2つが考えられた。

1. コントロールのスレッド処理の不具合
   スレッドセーフでない部分がどこかにあるのだろう、と推測した。
2. VB6.0のクラス継承の不具合
   この時点で初めて知ったのだが VB6.0ではクラス継承が事実上できない。インターフェースの継承はできるとされているが、実装の継承ができないのである。（それで継承っていえるのかな）
   それにもかかわらず、なぜか同じコントロールを複数配置することはできる。配列にすらできる。それらがプロセスならともかく、ハードウェアが絡んだ時に、どういう理屈で処理されているのかいまいちわからないところがある

もとをいえば、MSCommコントロールはWindows3.1 ・1992年のVB2.0からあるコントロールで、つまり16bitだった頃から受け継がれている。
時代背景を考えればスレッドセーフでなくても不思議ではない。というか当然なのかもしれない。

いずれにせよ、この問題の解決には API（DLL）を自分で最初から作る必要があるかもしれなかった。そして、それは時間的に現実的な解ではなかった。
「KONDERU-NDA」での実装は、.net の SerialPort クラス（スレッドセーフ）を使っていたこともあって、この問題は生じていなかった。
まったく、うかつだった。

1.7の保守ストリーム中に解決策が浮かべば対応することにはしたので、

• dablack.accdb には、Book1 と Book2の 2つのテーブル
• 拡張用のSlot （ライセンス認証 入力フォーム）

は、そのまま残すことにした。
「ダブルタップ」は、マルチタップに仕様を変えて実装されることになった。

ダブルタップは 1.8系でも実装する予定はないが、別の機能としてそれに近い動作ができるようにしたいと考えている。

（つづく）

なぜVisual Basicを使うのか

DAブラックホール1.x系列は、一貫して「Microsoft Visual Basic」(VB6.0)を用いて作られている。
正直言うと、この古い環境は わりとキツい。特に「クラス」を使うときは、いろいろ気を遣う言語仕様だからである。

それでもこのプラットフォームを使用するのは、DAブラックホールのユーザーには依然として Windows95/98を使っている方が少なくないからである。

NTT INS64（ISDN）がOCNエコノミーによって大きく流行り始めたころを思い出してほしい。ISDNプロトコルモニターなど計測器の需要が爆発的に伸びたあのころ、世の中はWindows95/98で動いてるPCばかりであった。このため、ISDN用の計測機器ではWindows95/98を実装しているものが少なくない。I/Oドライバーは16bitネイティブを32bitに置き換えたもの、あるいは16/32bitが混在している機器もある。

このため、これらの機器を動かすOSはWindows95/98でなければならない。そしてDAブラックホールはこれらのシステムで動かなければならない。

「Microsoft Visual Basic」(VB6.0)は、1998年に完成した最後のWin32ネイティブであり、Windows10に至った現在においても、ほぼ問題なく動作する稀有なプラットフォームである。
こんな20年近く前のプラットフォームが問題なく動作する背景には、Officeに入っているVBA(VisualBasic for Applications)のメンテナンスが、現在もマイクロソフトで続いているということもあるだろう。

DAブラックホール1.7各エディション（Windows2000以降用）が、そのままWindows95/98で動作するわけではないが、少しの手直しとDLLの交換で動作するようには作っている。
個人的にはVB6.0用の通信プログラムに関する連載を専門誌で行っていたことがあって（単行本にもなった）、その点で 経験的にはわりと有利であるかなとは思う。

ただ、いまは .net 環境にすっかり慣れてしまっているので、どうしてもその勢いでVB6.0を使ってしまうところがあって、DAブラックホール1.7でも 何度か致命的な失敗をしてしまうことになった。

（つづく）

サポート体制の変更

「キャリア判定（NTT・KDDI・SB・などなど）に使用する」ということは、利用者はかならずしも電話回線に詳しいわけではない。
アウトバウンド（テレアポ）をしている営業担当者が、いきなり導入を命じられることだってあるだろう。
すなわち 利用者（対象）の想定が大きく変わることになるので、1.7ではサポート体制の変更も必要になった。

まず「ハードウェアセットアップ」を新設して、宅配便でPCを送ってもらえば、セットアップして返すようにした。なお故障品を送られると困るので、いったんヤマト運輸の営業所止めにして、検品後に自社配送センターで収受→テクニカルサポートが整備して送り返す手順となった。東京・神奈川・埼玉・千葉では出張サポートも利用できるようにした。

つぎに「アドバイザリー」を拡充して遠隔メンテナンスのサービスを行うようにした。
1.7にパスコード（旧版の準裏コマンド）を入力すれば、リモートツールが起動し、担当者とチャット・通話・リモート操作が行えるようにした。この二段構えで、PCが不得手な人でも、導入可能な体制を整えた。

もともとのDAブラックホールは、ユーザーに対して排他的なソフトウェアだっただけに、回線技術者以外でも使えるようにすることは、サポート体制を根底から見直さざるをえないということでもあった。

ユーザー情報を破棄

とはいえ、サポート量の増大にあわせてスタッフを増やすことは、人件費上のリスクを負い製品原価を上昇させてしまうので、これを変動費にするべくユーザーサポートを外部に委託する必要があった。

だが、そうなると販売情報（個人情報）も外部に提供しなければならない。
これは懸念材料（クリティカルポイント）を増やしてしまうことであった。

そこでダイアモンドアプリコットはユーザーの個人情報を原則・持たないことにした。これまでのデータも経理上の伝票（証憑書類）以外は破棄することにした。
それでどうやってユーザーを識別するかというと、

1. ユーザーはサポートを受ける際に、ダイアモンドアプリコット電話研究所のサイトで、ライセンスカードの内容を入力し、正規ユーザーの認証を受ける
2. サポート会社には認証に成功した結果だけを通知する
3. ユーザーのメールアドレスは、フォーム入力時に使用したものを伝える

というデータフローにした。

この順序をユーザーが意識することはない。
質問をフォームに入力した時点で、自動的に処理されているからである。
ハッシュ保存された記録と照合して、購入記録のないユーザーからの質問のみライセンスカードの内容を入力する必要がある。

現在は、親会社の「ダイアモンドアプリコット」がサポートを担当しており、そこで手に余る内容の時には、「電話研究所」のテクニカルサポートが対応するようになっている。

（つづく）

仕様の策定

DAブラックホール1.7では、現行版(1.6)で表面化した課題の解決が目標であったがゆえに、スクラッチからの企画とは異なり、仕様の策定は早く進んだ。
以下はその主な優先順位と内容である。

1. スタビライザーの実装
   交換機からの応答時間の精度補正と、PC本体やTA（携帯電話）の速度のバラツキの補正の両面を行い、解析時間に反映することにした。もちろんキャリア判定が視野に入った機能である。
2. Windows7への完全対応
   1.6ではXPモードまでの対応だったのに対し、Vista/7への対応（主にUAC）が必須であった。市場ではすでにWindows7が販売されており、Windows8の販売も目前の状態であった。デベロッパーとしてはあまりに遅いタイミングといえたが、前回 述べたとおり1.6で打ち止めのつもりであったから、これはもう いたしかたなかった。
3. データベースエンジンの変更
   1.6まではMicrosoft Jetデータベースエンジン(*.mdb)を使用していたが、1.7ではADOを用いることにした。データベースファイルも*.accdbに変更とした。
   これは最終的に「外部データ連結（外のファイルを読み込み、外に書き戻す）」の実装が前提であったが、可能であればMS SQLやOracle、MySQLへの接続を利用者にも提供することを目指した。最終的には、ローカルファイルやネットワークファイルへの接続にとどめ、SQLサーバーへの直接接続は見送った。
4. ダブルタップ
   異なるキャリアを使用して「同時」に解析する機能。
   ISDN+PHS または FOMA+PHS の組み合わせで使用する前提であった。
   なおこの機能は、最終的に実装されず「マルチタップ」として、複数を順次解析する機能に変更した。その事情は別の機会に述べる。
5. マルチライセンス対応
   複数のライセンスをひとつのDAブラックホールにまとめ、同時運用できる機能。
   先述のダブルタップもこの機能によってアクチベートされる予定だったが、テスト段階で深刻なトラブルに見舞われ、1.7では対応を見送る結果になった。

製品グレードの導入

さらに仕様と関連して、売価設定に初めて「グレード（エディション）」を導入し、価格傾斜をつけた。

たとえばキャリア判別を初めて行う人には、キャリア別に複数のエディション（ISDN+PHS または FOMA+PHSなど）を購入するのは高くつく。
それならと、全部入りにして安く好き放題にしてもらえるグレード「Professional」を設定した。

初めての人に Professional もないとも考えたが、実際には業務利用の方に最も購入されるバージョンとなった。（バラで買うよりも圧倒的に安いというのもあろう）

また正式に「2クライアント運用」をStandard/Professionalに認めることで、従来より実質値下げとした。ライセンス認証もこのエディションについては2本同時購入として取り扱っている。
ただし従来の1.6のような「1ライセンス/1クライアント」として導入したい方もおられるだろうから、Elements という 1.6の価格を据え置いたエディションも用意した。機能も1.6と同じだが、こちらは1.6の更新(Windows7移行)を目的とした方と、難関チケット攻略といった「趣味の方」に重宝されることになった。

（つづく）

DAブラックホール1.7とはなんだったのか

2017年4月22日のアップデート・バージョン1.7.28をもって、1.7系で予定されていたすべての実装を完了した。

ただ、現在進行中の1.8系は、1.7.26からブランチされている。
今後も1.8系の継続によってバグがみつかったり、移行可能な改善点があれば、1.8系の恩恵というかたちで1.7に適用されていく予定だ。（1.7系のサポート終了まで）

とはいえ、1.7系の積極的なストリームはこれで終了となるので、この時点で
「1.7とはなんだったのか」
をふりかえってみる。

 

当初 1.7は計画になかった

もともと、DAブラックホールシリーズは1.6を最終版とする予定だった。
モバイル重視の2.0の開発計画も立ち上がっていたが、予想外にKDDI（au）のPSTN撤退が早く行われ、またウイルコムの事業的な行き詰まりも見え始めていたため、これ以上 PSTN網用のアナライザー開発を行うことは事業としては躊躇（ちゅうちょ）があった。
したがって 1.7があるとしても、Windows7用のローカライズバージョンになるだろうとして、申し訳程度の計画を2014年のガントチャートに置いていた程度だった。

ところが、フタをあけてみると 1.6系統の 企業カスタマイズ版である「docomo版」とPHS版の発注が予想を超えて多かった。
これは携帯電話販売店が「自社の顧客リストから」「かつての顧客が現在どのキャリアを使っているか」を調べたい、という要求によるものである。

たとえばMNPした顧客をDAブラックホールを使って探し出し、「もどってきなさい」「おかえりなさい」の営業をかけるといった用途などである。2011年にauがiPhoneを販売しはじめてからは、この用途が過熱していたという印象がある。

携帯電話キャリアの判別は、2001年のDAブラックホール1.3 FOMAキットですでに確立していたが、これが携帯電話販売店で細々と使用されていたにすぎなかった。
それを、独立して営業をはじめた方々が、一斉に活用をはじめた恰好であった。じつに10年経過して この部分でヒットが起きるというのは驚きだったし、この出来事はモノづくりと販売力・提案力の考え方に大きな示唆を与えてくれた。

ただ、携帯電話のキャリア判別を行うにあたっては、さらなる精度の向上が必要であった。1.6ではキャリア誤判定率が2割近くにのぼり、歩留まり向上のためには複数解析による精度補完が必須であった。これは利用現場のリソースを圧迫しかねなかった。

そこで、1.6をベースに最小限のエンジン改変によって、「キャリア」「モバイルキャリア」の各切り分け・判定能力を向上させたバージョン「1.7」の全体像が決まった。

（つづく）