Articles

Introduction The EV charging market is growing fast — and the software layer underneath it is where the real competitive advantage lives. Whether you’re a mobility startup, an energy company, or an enterprise spinning up an internal fleet charging solution, building your own white-label OCPP platform gives you control, scalability, and brand ownership that off-the-shelf […]

The Hidden Software Behind EV Charging Networks When people see an EV charger, they think about electricity. But behind every EV charging station is actually a distributed software system. A modern EV charging network includes: thousands of chargers cloud backend servers mobile applications payment systems real-time monitoring platforms

一份清晰的入门指南，详解 Wazuh 解码器与规则如何协同工作——字段是什么、从哪里来、何时需要解码器，以及日志如何变成告警。 标签： Wazuh · OSSEC · SIEM · 蓝队 · 检测工程 难度： 入门 → 中级 | 阅读时间： 15 分钟 如果你曾打开 Wazuh 规则文件，然后问自己： "这个字段从哪里来——规则、解码器，还是日志本身？" "这条规则要生效，我真的需要解码器吗？" "明明日志里有这个字符串，为什么 <field> 规则就是不触发？" ……你不是一个人。这些正是大多数人刚开始写 Wazuh 规则时必然会遇到的问题。本文将逐步解答所有疑惑，并在每个阶段配以流程图。

Wazuh のデコーダーとルールがどのように連携するかを初心者にも分かりやすく解説。フィールドとは何か、どこから来るのか、デコーダーが必要なタイミング、そしてログがアラートになるまでの流れを説明します。 タグ: Wazuh · OSSEC · SIEM · Blue Team · Detection Engineering レベル: 初級 → 中級 | 読了時間: 15 分

คู่มือฉบับสมบูรณ์สำหรับมือใหม่ — อธิบายว่า Wazuh decoders และ rules ทำงานร่วมกันอย่างไร, field คืออะไร, มาจากไหน, เมื่อไหรต้องใช้ decoder และ log กลายเป็น alert ได้อย่างไร Tags: Wazuh · OSSEC · SIEM · Blue Team · Detection Engineering ระดับ: มือใหม่ → ระดับกลาง | เวลาอ่าน: 15 นาที ถ้าคุณเคยมองไฟล์ Wazuh rule แล้วถามตัวเองว่า: "field นี้มาจากไหนกันแน่ — จาก rule, decoder หรือ log ตัวเอง?" "จำเป็นต้องมี decoder ไหมถึงจะให้ rule […]

A clear, beginner-friendly guide to how Wazuh decoders and rules work together — what fields are, where they come from, when you need a decoder, and how logs become alerts. Tags: Wazuh · OSSEC · SIEM · Blue Team · Detection Engineering Level: Beginner → Intermediate | Read time: 15 min If you’ve ever looked […]

引言 在中国制造2025战略和工业互联网政策的推动下，中国制造业正经历从"制造大国"向"制造强国"的历史性跨越。长三角、珠三角和京津冀等制造业集群中，越来越多的企业意识到：仅靠压低人力成本已无法维持竞争优势，提升设备效率与数字化管理能力才是可持续发展的核心。 然而，许多工厂仍依赖纸质点检表、班次结束后的手工统计，或孤立的Excel报表——管理者无法实时掌握车间正在发生什么。 OEE（Overall Equipment Effectiveness，设备综合效率） 是衡量制造生产效率的国际标准指标。实时OEE追踪系统能将问题发现从"报告后得知"变为"发生时即知"。本指南将带你从零开始构建这套系统——从传感器接入到实时看板，全程详解。

はじめに 日本の製造業は長年にわたり、カイゼン・トヨタ生産方式（TPS）・5Sを通じて世界最高水準の生産効率を追求してきました。しかし、多くの現場では依然として手書きの点検表、シフト終了後の日報、または連携していないExcelシートに頼っており、管理者はリアルタイムで現場の状況を把握できていません。 OEE（Overall Equipment Effectiveness／設備総合効率） は、製造現場の生産性を測る国際標準指標です。リアルタイムOEE管理システムを導入することで、問題を「報告で知る」から「発生した瞬間に知る」へと転換できます。 本ガイドでは、センサー連携からライブダッシュボードまで、システムをゼロから構築する方法を具体的に解説します。

บทนำ ในยุคที่ประเทศไทยกำลังเดินหน้าสู่ ไทยแลนด์ 4.0 และนโยบาย EEC (เขตพัฒนาพิเศษภาคตะวันออก) ดึงดูดการลงทุนจากอุตสาหกรรมยานยนต์ อิเล็กทรอนิกส์ และอาหารแปรรูประดับโลก การวัดและปรับปรุงประสิทธิภาพการผลิตจึงกลายเป็นสิ่งจำเป็น ไม่ใช่ทางเลือก OEE (Overall Equipment Effectiveness) หรือ ประสิทธิผลโดยรวมของอุปกรณ์ คือตัวชี้วัดมาตรฐานสากลที่ใช้วัดประสิทธิภาพการผลิต แต่โรงงานส่วนใหญ่ในไทยยังพึ่งพาการบันทึกข้อมูลด้วยมือ รายงานปลายกะ หรือสเปรดชีตที่ไม่เชื่อมต่อกัน ทำให้ผู้จัดการไม่รู้ว่าเกิดอะไรขึ้นบนพื้นโรงงาน ณ ขณะนั้น ระบบติดตาม OEE แบบเรียลไทม์เปลี่ยนสถานการณ์นี้ได้อย่างสิ้นเชิง คู่มือนี้จะพาคุณสร้างระบบดังกล่าวตั้งแต่ต้น ตั้งแต่การเชื่อมต่อเซ็นเซอร์ไปจนถึง Dashboard แบบสด

Introduction Overall Equipment Effectiveness (OEE) is the gold standard metric for measuring manufacturing productivity. Yet most factories still rely on manual data collection, end-of-shift reports, or disconnected spreadsheets — leaving managers blind to what’s happening on the floor right now. A real-time OEE tracking system changes that entirely. By capturing machine data as it happens, […]

บทนำ ในอดีต ระบบซอฟต์แวร์สำหรับองค์กร (Enterprise Software) มักถูกมองว่าเป็นระบบที่ต้องใช้เงินลงทุนมหาศาล หลายบริษัทต้องจ่ายตั้งแต่หลักแสนจนถึงหลักล้านดอลลาร์เพื่อซื้อ ERP ระบบความปลอดภัย หรือระบบ Automation จากผู้ขายรายใหญ่ นอกจากค่า License แล้ว ยังมีค่าใช้จ่ายอื่น ๆ เช่น ค่าที่ปรึกษา ค่า Implementation ค่า Maintenance รายปี ค่า Customization แต่ปัจจุบัน โลกของ Enterprise Software กำลังเปลี่ยนแปลงอย่างรวดเร็ว การรวมกันของ Open‑Source Software และ Artificial Intelligence (AI) ทำให้บริษัทสามารถสร้างระบบองค์กรที่มีความสามารถสูงได้ด้วยต้นทุนที่ต่ำกว่ามาก และนี่ไม่ใช่แค่การลดค่าใช้จ่าย แต่เป็น การเปลี่ยนวิธีการสร้างระบบองค์กรทั้งหมด

Introduction For decades, large enterprises relied on massive proprietary software systems. These platforms promised reliability, scalability, and support—but they often came with extremely high costs, long implementation timelines, and vendor lock‑in. Today, something fundamental is changing. The combination of open-source software and artificial intelligence (AI) is creating a new generation of enterprise systems—systems that are […]

缓存是提升电商平台性能最有效的手段之一，但同时也是最容易损害用户信任的方式。设想一下：用户将商品加入购物车时显示 ¥299，结算时却被收取 ¥599——他大概率不会再回来。或者，一件已经断货三小时的商品仍然显示"加入购物车"按钮，等待着的只是一张投诉工单。 本文将介绍如何针对正确的数据，设置合理的 TTL，并搭配有效的失效策略——在获得缓存性能红利的同时，保证数据的准确性。

キャッシュはECサイトのパフォーマンスを向上させる最も効果的な手段のひとつです。しかし同時に、顧客の信頼を損なう最も手軽な方法でもあります。カートに¥1,290で追加した商品が、チェックアウト時に¥1,790で請求されたとしたら——その顧客が再び戻ってくる可能性は極めて低いでしょう。あるいは、3時間前に売り切れた商品に「カートに追加」ボタンが表示されたままになっていれば、問い合わせが殺到することになります。 このガイドでは、正しいデータを正しいTTLでキャッシュし、適切な無効化戦略を組み合わせることで、速度と正確性を両立する方法を解説します。

การ Caching คือหนึ่งในวิธีที่เร็วที่สุดในการเพิ่มประสิทธิภาพร้านค้าออนไลน์ — และในขณะเดียวกันก็เป็นหนึ่งในวิธีที่ง่ายที่สุดในการทำลายความไว้วางใจของลูกค้า ลองนึกภาพลูกค้าที่กดเพิ่มสินค้าลงตะกร้าในราคา ฿1,290 แต่ถูกเรียกเก็บเงิน ฿1,790 ตอน checkout — โอกาสที่เขาจะกลับมาซื้ออีกครั้งนั้นแทบจะเป็นศูนย์ หรือปุ่ม "เพิ่มลงตะกร้า" บนสินค้าที่หมดสต็อกไปแล้วตั้งแต่สามชั่วโมงก่อน ก็คือ Ticket แจ้งปัญหาที่รอวันเกิดขึ้น คู่มือนี้จะอธิบายวิธี cache ข้อมูลที่ถูกต้อง ด้วย TTL ที่เหมาะสม และกลยุทธ์การ Invalidation ที่ดี — เพื่อให้ได้ประโยชน์ด้านความเร็วโดยไม่เสียความแม่นยำ

Caching is one of the fastest ways to improve ecommerce performance — and one of the easiest ways to destroy customer trust. A user who adds an item to their cart at $49, only to be charged $79 at checkout, will not come back. A "Add to Cart" button on a product that’s been out […]

将AI集成到遗留系统是企业数字化转型中最关键、也最容易被低估的工程挑战之一。大多数AI项目的失败并非源于模型本身，而是因为数据存放在运行了15年的SAP实例中、使用专有协议的SCADA历史数据库中，或是无人敢碰的本地Oracle数据库中。 AI层本身的构建并不困难。真正让项目陷入停滞的，是从根深蒂固的遗留系统中提取干净、一致、实时的数据，并将处理结果回写到业务运营工作流中。

レガシーシステムへのAI統合は、エンタープライズのデジタルトランスフォーメーションにおいて最も重要でありながら、最も過小評価されがちなエンジニアリング課題のひとつです。AIプロジェクトの多くが失敗する原因はモデルにあるのではありません。15年稼働しているSAPインスタンス、プロプライエタリなプロトコルを使うSCADAヒストリアン、あるいは誰も触りたがらないオンプレミスのOracleデータベース——データがそこに存在し続けることが根本的な問題です。 AIレイヤー自体の構築は難しくありません。プロジェクトが停滞するのは、レガシーシステムからクリーンで一貫したリアルタイムデータを抽出し、その結果をオペレーショナルなワークフローに戻すという統合作業においてです。

การ Integrate AI เข้ากับระบบ Legacy คือหนึ่งในความท้าทายด้านวิศวกรรมที่สำคัญที่สุด — และมักถูกประเมินต่ำที่สุด — ในการทำ Digital Transformation ขององค์กร โครงการ AI ส่วนใหญ่ไม่ได้ล้มเหลวเพราะตัว Model แต่ล้มเหลวเพราะข้อมูลถูกเก็บอยู่ใน SAP ที่ใช้มา 15 ปี, SCADA Historian ที่ใช้ Protocol แบบ Proprietary หรือฐานข้อมูล Oracle On-Premise ที่ไม่มีใครกล้าแตะ ส่วน AI Layer นั้นทำได้ไม่ยาก สิ่งที่ทำให้โครงการติดขัดคือการดึงข้อมูลที่สะอาด สม่ำเสมอ และ Real-time ออกจากระบบ Legacy ที่ฝังรากลึก — แล้วส่งผลลัพธ์กลับเข้าสู่ Workflow ปฏิบัติการ คู่มือนี้ครอบคลุม Technical Pattern, Integration Strategy และการตัดสินใจด้านสถาปัตยกรรมที่ทีมวิศวกรต้องเข้าใจก่อนคัดเลือก Vendor สำหรับ […]

Integrating AI into legacy systems is one of the most critical — and most underestimated — engineering challenges in enterprise digital transformation. Most AI initiatives don’t fail because of the model. They fail because the data lives in a 15-year-old SAP instance, a SCADA historian with a proprietary protocol, or an on-premise Oracle database that […]