Tag: it

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (3) – 自覚症状が無いセンサデータの品質問題

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 今回から、「自覚症状が無いセンサデータの品質問題」に関連した話題をお伝えしていきます。  結果が出ないPoC(Proof of Concept:概念実証)  SASは世界各国に支社を持ち、製造業DXの実現に向けた数多くのデータ分析案件を取り扱っています。 よく頂く御相談内容としては、生産品の品質管理と設備保全系に関連するデータ分析システムの導入検討です。(図1)    図1. 生産ライン向けDXとしてよくある御相談   ところが、PoCとしてセンサデータを用いてデータ分析をしているが、思うような結果が得られていないというケースが市場で発生しています。多くの方がデータ分析手法に問題があるのではないかと考え、データ分析のスペシャリストである弊社に御連絡を頂きます。たしかに分析手法の問題もあり、原因は様々ですが、意外と盲点になっているのが分析対象となるセンサデータ自体の品質問題です。  センサデータの品質問題とは何か?  データ分析はデータ収集から始まります。そして、そのデータの質が分析結果に影響を与えることは容易に想像できます。図2はセンサデータ分析システムの構築の流れを示しています。システム構築は、データ収集からスタートし、データ蓄積、そしてデータ分析という順番で実施され、手動でデータ分析の結果が出るようになった段階で自動化するという流れが一般的です。  図2. センサデータ分析システムの構築の流れ   図3は、センサデータの分析の際にAIの導入を意識して描いたものです。流れとしては、経営上の目標設定から始まり、データ取得、特徴量抽出/次元削減、そしてモデル作成へと進んでいきます。ここで皆様に質問させて頂きたいのは、どの工程が一番重要なのかということです。無論、どの工程も専門家の知見が必要であり、重要かつ難易度が高いのは当然ですが、最も重要なのは前半のデータ取得と特徴量抽出だと、あえて強調します。言い換えますと、モデル作成に使用されるセンサデータの品質(精度)が重要だということです。当然ではありますが、センサデータの質が悪い場合、データ分析(作成するモデルの精度)に影響が出てしまうためです。 医者の診断に例えれば、検査データが間違っていたら間違った診断を下してしまうのと一緒であり、センサデータの品質は極めて重要だと言えます。  図3. AIを用いたセンサデータ分析システムの開発の流れ 自覚症状が無いセンサデータの品質問題  この問題の恐ろしい点は、システム開発に携わっている関係者の皆様にとって自覚症状が表れない場合が多いことです。 そもそも、データ分析の結果が出ない原因が、上述のセンサデータの質に関係していることを、どうやって判断すれば良いのでしょうか? 当然、他の原因も考えられます。   先日、お医者様と健康診断の検査結果のお話をした際に気がついたのですが、お医者様は検査データの意味や限界、誤差要因をよく御存知のようでした。そして総合的に私の健康状態を判断しておられるようでした。思わず、その秘密を知りたいと思い質問してしまったのですが、お医者様の回答は「過去の事例と経験即かなぁ~~??」と、お答えいただきました。  ということで、次回以降、私の経験即に基づいたチェックポイントを御紹介していきます。  前回のブログ  次回に続く

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (2) - 生産ラインにおけるAIを用いた状態監視の種類

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。 そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 はい、今回は、「生産ラインにおけるAIを用いた状態監視の種類」について解説します。 図1に示した通り、種類としては4つに大別されます。 どれを実現したいのかで、取得すべきセンサデータの種類や、データ分析システムの構築難易度が変わってきます。 読者の皆様は、どれを実現したいとお考えでしょうか? 図1.生産ラインにおけるAIを用いた状態監視の種類は4つある 1つ目が異常検知です  これは生産品の品質異常や生産ラインの設備機械の異常を捉えるものであり、学術的には「教師なし学習」と呼ばれる手法を用います。この場合、異常時のデータを予め用意する必要がないため、不具合データの取得が困難な製造業の現場において有効となります。例えば、正常時の各種センサデータを基準とし、どれだけ正常状態から離れたかで、異常を検出する方法です。 2つ目は原因診断です これは異常発生後に、何が原因なのか特定するものであり、学術的には「教師あり学習」と呼ばれる手法を用います。この場合、異常時のデータを予め用意しておく必要があります。 原因診断が必要とされる理由としては、対処方法の検討をつけるためです。 製造装置であれば、点検箇所や分解すべき箇所を特定することにより、分解コストや部品交換コストを抑えることができます。 これは大型機械の場合、特に重要であり、この原因診断は「精密診断」とも呼ばれ、まさに職人技が要求される分野です。 3つ目が品質/寿命予測です これは各種データから、生産品の品質を予測したり、稼働中の設備や部品が、あとどれくらい使用できるか日数を予測するものです。 例えば、生産品の品質予測が可能になると、抜き取り検査の精度が向上し、ランダムにサンプル取得をするのではなく、品質上懸念がありそうなものをサンプルして効率良く評価できるようになります。 また、設備や部品の寿命予測が可能になれば、高額な部品をできるだけ長く使用することができますし、メンテナンス日程を戦略的に決めることも可能になります。 4つ目がパラメータ最適化です これは、期待した品質で生産するためには、どのような製造環境や材料構成が必要なのか、また、どのように製造装置を制御したらよいのか決定することができます。 図1に示したデータ活用の流れは、人間の健康診断と全く同じであり、1番から4番まで順番に実施する必要があり、飛び越えることはできません。 医療に例えますと、1番の「異常検知」は、正常時との変化を検出するものであり、いわば定期健康診断に相当するものです。 2番の「原因診断」は、定期健康診断で早期発見された異常を、さらに掘り下げて精密検査を行うものです。 3番の「品質/寿命予測」に関しては、医学でも同様であるが、これまでの長年にわたるデータが揃うことにより、治癒率予測が可能になります。 4番の「パラメータ最適化」は、健康で過ごすための予防方法だと言えます(図2)。そして、豊かな人生を過ごすために、どなたも4番の予防までを期待されておられると思います。 図2. 医療診断の流れと、生産ラインにおける品質管理/設備状態監視の流れはよく似ている 生産ラインでも同様です。最後の4番まで実現できれば、ビジネス上の費用対効果(ROI)は最大となります。 それには、分析に必要な各種データを準備する必要があり、その質も重要になります。 しかしながら現実問題として、いきなり4番から実現することはできないため、4番のパラメータ最適化の実現をゴールとしながら、1番から順番に実現していく必要があることを御理解ください。また、医学でも同様のことがいえるかと思いますが、生産ラインにおける状態監視対象物によっては、1番の異常検知が技術的な限界となり、2番以降に進めない場合もあります。 この見極めも重要となってきますが、この点は本ブログのテーマとして別途取り扱いたいと思います。 前回のブログ  次回に続く

Analytics | SAS Events
SAS Global Forum 2019 論文紹介シリーズ 第4回「オペレーショナル・アナリティクス for IT」

前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス for Data Scientist」ユースケースの論文を紹介しました。今回は、企業様にとって、クラウド上のインフラアーキテクチャと分析プラットフォームのデプロイメントについて、ご紹介します。昨今、なぜ「コンテナ」が注目されているのか、そして、クラウドやコンテナ上に分析プラットフォームを移行/構築し、活用することに関心があるのであれば、ぜひ最後までご覧ください。 1.Cows or Chickens: How You Can Make Your Models into Containers モデルは特定の作業(新しいデータをスコアリングして予測を出すこと)として役割を果たしてきています。一方、コンテナは簡単に作成し、廃棄し、再利用できることができます。実際、それらは簡単にインテグレートさせ、パブリッククラウドとオンプレミス環境で実行できます。SASユーザは本論文を通じて、簡単にモデルの機能をコンテナに入れることができます。例えば、パブリッククラウドとオンプレミス環境でのDockerコンテナ。また、SASのModel Managerは様々なソース(オープンソース、SAS、コンテナ等々)からモデルの管理を行うことができます。したがって、この論文はそれらの基本知識と、どのようにSASの分析モデルをコンテナに入れることをメインに紹介します。 2.Orchestration of SAS® Data Integration Processes on AWS この論文では、Amazon Web Services(AWS)S3でのSASデータインテグレーションプロセスの構成について説明します。例としては、現在サポートしているお客様がクレジット報告書を生成するプロセスを毎日実行しています。そして、そのお客様の対象顧客は1カ月ごとに1回その報告を受け取ります。データ量としては、毎日に約20万の顧客情報が処理され、最終的に毎月約600万人の顧客へ報告することとなります。プロセスはオンプレミスデータセンターで始まり、続いてAWSのSASデータインテグレーションでAPR計算が行われ、最後にオンプレミスデータセンターで報告書が生成されます。さらに詳しい情報としては、彼らのアーキテクチャ全体はマイクロサービスを使われていますが、同時にAWS Lambda、簡易通知サービス(SNS)、Amazon Simple Storage Service(Amazon S3)、およびAmazon Elastic Compute Cloud(EC2)などの独立した高度に分離されたコンポーネントも使われています。つまり、それらにより、データパイプラインに対するトラブルシューティングが簡単になっていますが、オーケストレーションにLambda関数を使用することを選択すると、プロセスがある程度複雑になります。ただし、エンタープライズアーキテクチャにとって最も安定性、セキュリティ、柔軟性、および信頼性もあります。S3FやCloudWatch SSMのようなより単純な代替手段がありますが、それらはエンタープライズアーキテクチャにはあまり適していません。 3.SAS® on Kubernetes: Container Orchestration of Analytic Work Loads 現在、Big Dataの時代で、Advanced analyticsのためのインフラストラクチャに対するニーズが高まっています。また、分析自体に対して、最適化、予測が最も重要領域であり、小売業、金融業などの業界ではそれぞれ、分析に対する独自の課題を抱えています。この論文では、Google Cloud