Việc kết hợp một hệ thống giao diện người-máy (HMI) có thể mở rộng và kiểm soát giám sát và thu thập dữ liệu với chức năng cạnh bổ sung mang lại cho các thiết kế máy móc và nhà máy một mức độ linh hoạt và khả năng thích ứng cao để nhanh chóng phản ứng với môi trường thị trường thay đổi và duy trì các chu kỳ đổi mới nhanh chóng.

Mọi thứ trong kỹ thuật và công nghệ đang thay đổi nhanh chóng và chúng ta phải thích ứng. Những thay đổi trong  cuộc sống hàng ngày  là  đôi khi nhỏ  và  hầu như không đáng kể ;  đôi khi  họ đang  lớn  và có  tác động ngay lập tức  trên  tất cả mọi người. 

Tất cả những thay đổi này cũng ảnh hưởng đến sản xuất và cách những người liên quan chuẩn bị sản xuất cho tương lai.  Một trong những thách thức lớn nhất mà các công ty vẫn phải đối mặt là tăng tính linh hoạt và thời gian đưa ra thị trường đồng thời giảm chi phí sản xuất. Mặc dù thách thức này không mới, nhưng áp lực phải thích ứng đã tăng lên trong những năm gần đây. 

Công ty có thể làm gì hôm nay để chuẩn bị cho sản xuất ngày mai? 

Dữ liệu sản xuất ở khắp mọi nơi 

Các khái niệm sản xuất mới cho Công nghiệp 4.0 không dựa vào kim tự tháp tự động hóa cổ điển của Hiệp hội Tự động hóa Quốc tế (ISA) nữa. Thay vào đó, họ phân chia sản xuất thành các đơn vị nhỏ hơn và linh hoạt trao đổi dữ liệu ở nhiều cấp độ. 

Điều này đòi hỏi các hệ thống giao diện người – máy (HMI) linh hoạt và có thể mở rộng trong đó cùng một dự án và màn hình có thể được sử dụng trên bảng điều khiển HMI 7 inch, hệ thống điều khiển giám sát và thu thập dữ liệu (SCADA) hoặc điện thoại thông minh. Dữ liệu có sẵn trong thời gian thực trên mọi thiết bị khi cần thiết mà không cần nỗ lực lập trình.  

Điều này cho phép các  kỹ sư  thích ứng  với  sản xuất theo các yêu cầu luôn thay đổi trong khi sử dụng các thiết bị tự động hóa hiện có. 

WinCC Unified là nền tảng có thể chạy trên các thiết bị khác nhau, từ nhỏ đến lớn. nguồn : Siemens Industry Inc.

Tối ưu hóa liên tục 

Liên tục tăng năng suất là mục tiêu của mọi người. Thách thức là làm thế nào để điều chỉnh sản xuất trong khi giữ cho mọi thứ hoạt động trơn tru cùng một lúc. 

Đây là nơi các thiết bị cạnh có thể trợ giúp. Các thiết bị Edge cung cấp một nền tảng để chạy phân tích, bảo trì dự đoán và các công cụ khác giúp tối ưu hóa sản xuất mà không can thiệp vào chính sản xuất. 

Thiết bị tính toán  biên  có thể là  PC công nghiệp ( IPC )  hoặc chức năng biên có thể được tích hợp trong thiết bị tự động hóa như bảng điều khiển HMI. Bằng cách này, bảng điều khiển HMI đáp ứng cả hai yêu cầu, đảm bảo sản xuất ổn định trong khi cho phép mức độ linh hoạt cao trong việc chạy các chương trình hoặc công cụ mới giúp tăng năng suất. 

Một trường hợp sử dụng khả thi có thể là để thiết bị HMI điều khiển máy trong khi phần cạnh của thiết bị thu thập dữ liệu bổ sung để bảo trì dự đoán hoặc chạy các thuật toán phức tạp để tối ưu hóa máy. 

Tất nhiên, chức năng kết hợp này không chỉ có lợi cho các thiết bị HMI. Các  mô-đun, bộ điều khiển logic có thể lập trình ( PLC ) , ổ đĩa và thiết bị mạng có chức năng tích hợp cạnh cũng sẽ cho phép tăng năng suất hơn nữa. 

Tóm lại ,  việc kết hợp một hệ thống HMI có thể mở rộng bao gồm các HMI 7 inch cũng như các hệ thống SCADA với chức năng e dge bổ sung  mang lại một lợi thế độc đáo cho các  thiết kế máy móc và nhà máy trong tương lai  . Các hệ thống mới này cung cấp mức độ linh hoạt và khả năng thích ứng cao để nhanh chóng phản ứng với các môi trường thị trường đang thay đổi và trong khi duy trì các chu kỳ đổi mới nhanh chóng. 

Bài viết trên được biên soạn và chỉnh sửa bởi SmartFactoryVN.com . Các bạn sao chép xin ghi rõ nguồn bài viết.

Nguồn: smartfactoryvn.com

Bài viết Tự động hóa sẽ tương thích chuẩn điện toán biên mới đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.

Việc lựa chọn (các) nền tảng cơ sở dữ liệu phù hợp cho các giải pháp IoT là khá khó khăn. Một thách thức là vị trí — các giải pháp IoT có thể được phân phối trên các vùng địa lý. Trái ngược với cách tiếp cận dựa trên đám mây tập trung, nhiều giải pháp đang áp dụng sự kết hợp của cả điện toán sương mù ở biên và điện toán đám mây.

Các ứng dụng quan trọng thu thập khối lượng lớn dữ liệu và dựa vào độ trễ thấp đang ngày càng được đẩy mạnh, tuy nhiên, cần phải kết nối các máy chủ biên với đám mây. Do đó, các nền tảng cơ sở dữ liệu phải cung cấp tính linh hoạt để xử lý dữ liệu ở biên và đồng bộ hóa giữa các máy chủ biên và đám mây.

Một thách thức khác là sự đa dạng của các tính năng cần thiết để hỗ trợ các trường hợp sử dụng IoT. Các khả năng bạn muốn trong cơ sở dữ liệu của mình có thể từ truyền dữ liệu thời gian thực; lọc và tổng hợp dữ liệu; hoạt động đọc độ trễ gần bằng không; phân tích tức thì; tính khả dụng cao; phân phối địa lý; tính linh hoạt của lược đồ, v.v. Bài viết này hướng dẫn bạn qua bốn bước để chọn nền tảng cơ sở dữ liệu phù hợp cho Giải pháp IoT của bạn:

1. Xác định nhu cầu dữ liệu cho giải pháp của bạn,

2. Chia nhỏ giải pháp của bạn thành các dịch vụ độc lập và liệt kê các nhu cầu dữ liệu của chúng.

3. Nhóm các dịch vụ của bạn theo yêu cầu dữ liệu của chúng và chọn (các) cơ sở dữ liệu phù hợp,

4. Đánh giá hiệu quả chi phí và nguồn lực.

Xác định nhu cầu dữ liệu cho giải pháp của bạn

Một giải pháp IoT hoàn chỉnh không chỉ đơn giản là kết nối một thiết bị với internet. Các giải pháp IoT phụ thuộc vào việc thu thập và xử lý dữ liệu từ các thiết bị được kết nối, đưa ra các quyết định thông minh như kích hoạt thông báo hoặc hành động, tính toán phân tích thời gian thực, thu thập các mẫu từ dữ liệu lịch sử, v.v.

Để đơn giản hóa cuộc thảo luận của chúng ta, hãy giả sử một giải pháp IoT chung 1 mẫu. Trong giải pháp của chúng ta , chúng ta có các cảm biến và thiết bị truyền động được lắp đặt trong toàn doanh nghiệp. Hàng ngàn cảm biến và thiết bị truyền động kết nối với một máy chủ biên. Giải pháp IoT thu thập dữ liệu từ tất cả các cảm biến một cách liên tục và đưa ra các quyết định theo thời gian thực để điều khiển các cảm biến và thiết bị truyền động, cảnh báo các giám sát hệ thống về hoạt động bất thường và cung cấp cái nhìn lịch sử về số liệu phân tích cho người dùng cuối.

Trước khi bạn quyết định về các dịch vụ và cơ sở dữ liệu đi kèm với chúng, bạn cần phải biết rõ bạn đang làm gì với dữ liệu của mình và ở đâu. Những câu hỏi này giúp bạn hiểu và ưu tiên nhu cầu dữ liệu của mình:

• Cấu trúc liên kết của các máy chủ biên là gì? Cấu hình hệ thống của máy chủ biên là gì — có bao nhiêu RAM và bộ nhớ?
• Xử lý dữ liệu và ra quyết định nào được giao cho các máy chủ biên?
• Giải pháp đám mây được triển khai trong một khu vực hay phân tán trên nhiều khu vực?
• Cấu hình hệ thống của máy chủ đám mây là gì?
• Khối lượng dữ liệu được truyền từ thiết bị đến máy chủ biên và từ máy chủ biên đến máy chủ trung tâm là bao nhiêu? Ước tính cho khối lượng cao nhất là bao nhiêu?
• Các định dạng khác nhau của dữ liệu đến từ các thiết bị và các kỹ thuật chuẩn hóa, dịch và lọc được áp dụng trên dữ liệu là gì?
• Giải pháp IoT có kiểm soát các thiết bị hoặc bộ truyền động không? Nếu có, những tính năng thiết bị nào được kiểm soát bởi giải pháp IoT? Họ có yêu cầu phản hồi thời gian thực không?
• Thời gian quay vòng dự kiến ​​để phản ứng với bất kỳ sự kiện quan trọng nào?
• Phân tích thời gian thực được tính toán từ dữ liệu đến là gì?
• Thông tin chi tiết về doanh nghiệp thu được từ dữ liệu lịch sử là gì?
• Các dịch vụ bên ngoài phụ thuộc vào dữ liệu là gì?

Chia nhỏ giải pháp của bạn thành các dịch vụ phần mềm độc lập

Bước trước đó tập trung vào các câu hỏi liên quan đến “cái gì” và “ở đâu” của giải pháp của bạn. Bây giờ bạn sẽ trả lời làm thế nào. Trong bước này, bạn sẽ thiết kế các dịch vụ hoặc thành phần phần mềm thực hiện các tác vụ độc lập, cụ thể.

Khi bạn chia nhỏ giải pháp IoT mẫu được mô tả trước đó thành các dịch vụ độc lập, bạn có thể nhận được thiết kế như trong Hình 2. Bản thân giải pháp IoT được phân phối theo địa lý, nơi một số thành phần được triển khai trên mạng biên và những thành phần khác ở vị trí tập trung .

Nhóm các dịch vụ của bạn theo nhu cầu dữ liệu của chúng và chọn cơ sở dữ liệu phù hợp

Bây giờ bạn đã chia nhỏ giải pháp của mình thành các dịch vụ phần mềm và xác định nhu cầu dữ liệu của chúng, bước tiếp theo sẽ là chọn (các) cơ sở dữ liệu phù hợp. Trước khi bạn quyết định cơ sở dữ liệu, hãy vẽ biểu đồ tốc độ thời gian cho dữ liệu của từng dịch vụ. Trục thời gian cho bạn biết dữ liệu ở trong cơ sở dữ liệu không thay đổi trong bao lâu và trục tốc độ biểu thị tốc độ đọc / ghi dữ liệu theo yêu cầu của dịch vụ.

Khi chúng ta vẽ biểu đồ cho ví dụ IoT của mình và đính kèm các dịch vụ vào biểu đồ, biểu đồ sẽ giống như bên dưới. Ví dụ: dữ liệu liên tục đến và đi từ Máy chủ nhập dữ liệu. Do đó, dữ liệu sẽ nằm trong cơ sở dữ liệu trong một khoảng thời gian rất ngắn. Đồng thời, dữ liệu có thể đến với khối lượng và tốc độ cao. Do đó, chúng ta cần một cơ sở dữ liệu tốc độ cao với độ trễ thấp để giữ dữ liệu cho dịch vụ nhập. Công cụ phân tích đọc luồng dữ liệu liên tục, đưa ra quyết định theo thời gian thực và thực hiện các sửa đổi liên quan đối với cơ sở dữ liệu trên cơ sở liên tục. Mặt khác, dịch vụ tình báo kinh doanh dựa trên dữ liệu lịch sử.

Khi bạn đã hoàn thành với biểu đồ tốc độ thời gian, bước tiếp theo là nhóm các dịch vụ có đặc điểm truy cập dữ liệu tương tự. Việc nhóm các dịch vụ dựa trên nhu cầu dữ liệu của chúng giúp bạn giới hạn số lượng cơ sở dữ liệu trong môi trường của mình, giảm chi phí hoạt động. Quá trình này cũng giúp bạn loại bỏ các cơ sở dữ liệu không phù hợp với yêu cầu của bạn.

Trong giải pháp ví dụ của chúng tôi, chúng tôi nhóm các dịch vụ của mình thành hai cơ sở dữ liệu chính: cơ sở dữ liệu nóng và cơ sở dữ liệu lạnh. Kiến trúc cuối cùng, bao gồm các cơ sở dữ liệu, sẽ giống như Hình 4.

Các cơ sở dữ liệu, đặc biệt là những cơ sở dữ liệu lưu trữ dữ liệu nóng, được triển khai gần với các thiết bị để giảm thiểu độ trễ của mạng. Các lựa chọn cơ sở dữ liệu cho dữ liệu nóng và lạnh:

Cơ sở dữ liệu nóng

Do chi phí của RAM trở nên hợp lý hơn, cơ sở dữ liệu trong bộ nhớ thường là một lựa chọn tốt. Cơ sở dữ liệu trong bộ nhớ cung cấp khả năng đọc và ghi dữ liệu với độ trễ thấp nhất. Khi chọn một cơ sở dữ liệu nóng, bạn nên xem xét các khả năng sau để giúp bạn thu hẹp các tùy chọn cơ sở dữ liệu của mình:

1. Tính linh hoạt với các định dạng dữ liệu: Nếu bạn cần hỗ trợ nhiều loại thiết bị, thì bạn sẽ buộc phải hỗ trợ nhiều định dạng dữ liệu và giao tiếp. Tìm kiếm một cơ sở dữ liệu có thể hỗ trợ nhiều định dạng dữ liệu khác nhau.

2. Khả năng truy vấn: Giải pháp của bạn, đặc biệt là công cụ phân tích, sẽ truy vấn cơ sở dữ liệu để tính toán và suy luận thêm thông tin. Bạn nên xác minh tất cả các tính năng liên quan đến truy vấn, lập chỉ mục và tổ chức dữ liệu (ví dụ: cách tổ chức dữ liệu chuỗi thời gian).

3. Nhắn tin và hàng đợi : Bạn cần một giải pháp nhắn tin và hàng đợi mạnh để kết nối tất cả các dịch vụ trải dài khắp các vùng địa lý. Cơ sở dữ liệu hỗ trợ các luồng sẽ giúp bạn nhắn tin và hàng đợi cùng với việc chuyển đổi, phân tích và lọc dữ liệu — tất cả đều trong thời gian thực. Với mô hình xuất bản / đăng ký (thường được gọi là pub / sub), bạn có thể tách nhà sản xuất và người tiêu dùng, đồng thời xây dựng giải pháp IoT phân tán có tính linh hoạt cao.

4. Sự lan tỏa và mở rộng dữ liệu: Đối với nhiều giải pháp (cụ thể là các giải pháp IoT), dữ liệu phát triển rất nhanh. Khi bạn thiết kế dung lượng cho bộ lưu trữ nóng, bạn nên xem xét các tùy chọn loại bỏ và tràn. Nói cách khác, bạn nên có một kế hoạch cho những gì bạn sẽ làm nếu RAM của bạn đầy. Kiểm tra xem cơ sở dữ liệu tốc độ cao có cung cấp “quyền truy cập bộ nhớ theo cấp độ” hay không, trong đó bộ nhớ flash hoặc đĩa có thể được sử dụng làm bộ mở rộng RAM.

5. Tính khả dụng cao và khả năng phục hồi sau thảm họa: Giảm thiểu thời gian chết là điều cần thiết đối với hầu hết các doanh nghiệp. Phổ biến cơ sở dữ liệu trong bộ nhớ cung cấp tính khả dụng cao thông qua phân nhóm, sao chép trong bộ nhớ và phát hiện lỗi tự động, cũng như hỗ trợ khôi phục thảm họa thông qua tính bền bỉ và nhân rộng trên các trung tâm dữ liệu, vùng và khu vực.

6. Phân phối theo địa lý: Nếu mạng IoT của bạn được phân phối theo địa lý và nếu kiến ​​trúc của bạn yêu cầu một số dịch vụ của bạn phải ở gần các thiết bị của bạn, thì bạn có thể cần một cơ sở dữ liệu hỗ trợ phân phối theo địa lý.

7. Két an toàn nhị phân: Các giải pháp IoT thường lưu trữ dữ liệu nhị phân (video từ camera quan sát chẳng hạn). Giải pháp của bạn có yêu cầu lưu trữ và truy cập dữ liệu nhị phân không? Nếu có, thì bạn cần chọn một cơ sở dữ liệu là an toàn nhị phân.

Cơ sở dữ liệu lạnh

Dữ liệu lịch sử cho các giải pháp IoT có thể tăng lên nhiều terabyte, thậm chí vượt quá một petabyte trong một số trường hợp. Các lựa chọn phổ biến để lưu trữ dữ liệu lịch sử bao gồm các giải pháp lưu trữ trên phần cứng hàng hóa. Các truy vấn thường tuân theo mô hình thu nhỏ bản đồ. Thông thường, dữ liệu lịch sử cũng được lập chỉ mục trong công cụ tìm kiếm để đối sánh mẫu và tổng hợp dữ liệu. Nếu bạn đang lưu trữ dữ liệu trên đám mây, hãy kiểm tra với nhà cung cấp dịch vụ đám mây của bạn để xác định giải pháp lưu trữ dữ liệu nào hiệu quả nhất về chi phí trong khu vực của bạn.

Đánh giá chi phí và hiệu quả tài nguyên

Việc phân loại cơ sở dữ liệu thành hai loại — nóng và lạnh — không phải lúc nào cũng có nghĩa là bạn chỉ nên có hai cơ sở dữ liệu, nhưng làm như vậy có thể giúp bạn thu hẹp các lựa chọn cơ sở dữ liệu của mình. Đối với hầu hết các trường hợp sử dụng IoT, một cơ sở dữ liệu tốc độ cao có thể đáp ứng tất cả các yêu cầu cho cơ sở dữ liệu nóng của bạn.

Nếu bạn cần một cơ sở dữ liệu nóng thứ hai chuyên biệt, thì bạn chỉ nên đưa ra quyết định sau khi đánh giá kỹ lưỡng. Về lưu trữ lạnh, các tùy chọn có thể bao gồm từ cơ sở dữ liệu quan hệ đến hồ dữ liệu. Một sai lầm mà các kiến ​​trúc sư mắc phải là tạo ra một kiến ​​trúc đa ô với một cơ sở dữ liệu chuyên biệt cho từng dịch vụ. Điều này không chỉ làm tăng độ phức tạp của ngăn xếp ứng dụng mà còn cả chi phí và chi phí hoạt động.

Tổng chi phí sở hữu một cơ sở dữ liệu là một phép tính với nhiều yếu tố. Bản thân chi phí của cơ sở dữ liệu chỉ là một phần nhỏ trong tổng chi phí. Phần lớn chi phí liên quan đến việc sở hữu và vận hành cơ sở dữ liệu đến từ chi phí tính toán, mạng và tài nguyên lưu trữ, cũng như chi phí hoạt động. Một yếu tố quan trọng khác cần xem xét là chi phí mất dữ liệu và khả năng nó có thể xảy ra.

1. Chi phí License cơ sở dữ liệu: Chi phí cơ sở dữ liệu phụ thuộc vào mô hình định giá của nhà cung cấp. Chi phí có thể là một hàm của số lượng CPU; số lượng mảnh trong cụm; kích thước cơ sở dữ liệu; thông lượng (số lượng hoạt động tối đa mỗi giây); khoảng thời gian (hàng năm, hàng tháng, hàng giờ, v.v.); các tính năng cho tính khả dụng và phục hồi cao; tính khả dụng trong các vùng nhiều tầng của đám mây; v.v … Nếu bạn đang sử dụng cơ sở dữ liệu có sẵn dưới dạng phần mềm nguồn mở và tùy thuộc vào loại giấy phép bạn sử dụng, chi phí cơ sở dữ liệu thậm chí có thể là con số không.

2. Chi phí tài nguyên tính toán: Bạn có các lựa chọn hạn chế để mở rộng khả năng tính toán của các máy chủ biên trong môi trường sương mù, vì vậy bạn cố gắng điều chỉnh cơ sở dữ liệu mang lại cho bạn hiệu suất tốt nhất cho cấu hình phần cứng của bạn. Bạn có thể được yêu cầu đầu tư nhiều hơn vào RAM để có được (các) cơ sở dữ liệu nóng của mình hoạt động tốt hơn.

Về tài nguyên điện toán đám mây, chi phí của bạn chủ yếu phụ thuộc vào mức độ hiệu quả của cơ sở dữ liệu của bạn trong việc sử dụng tài nguyên. Ví dụ, một cơ sở dữ liệu nhẹ, an toàn theo luồng có thể thực hiện một triệu thao tác đọc / ghi mỗi giây chỉ với hai máy chủ hàng hóa, trong khi một số cơ sở dữ liệu truyền thống có thể yêu cầu hàng chục nếu không phải hàng trăm máy chủ để thực hiện cùng một số lượng hoạt động mỗi giây.

Ngoài hiệu quả cơ sở dữ liệu, chi phí đầu tư phần cứng của bạn là một chức năng của thông lượng, số lượng CPU, RAM, bộ nhớ flash, card mạng, v.v. Kiến trúc cơ sở dữ liệu để có tính sẵn sàng cao cũng đóng một vai trò. Ví dụ: kiến ​​trúc chuyển đổi dự phòng dựa trên túc số sẽ chỉ yêu cầu một bản sao của máy chủ phụ, trong khi kiến ​​trúc không dựa trên túc số sẽ cần hai bản sao dữ liệu để tránh bị phân chia.

3. Chi phí mất dữ liệu: Có một số điều bạn cần cân nhắc khi tính toán chi phí mất dữ liệu:

a. Doanh nghiệp của bạn phải chịu tổn thất gì nếu bạn làm mất dữ liệu trong cơ sở dữ liệu của mình?

b. Khả năng mất mát có thể xảy ra là gì?

c. Chi phí khôi phục dữ liệu là bao nhiêu?

d. SLA của nhà cung cấp của bạn có bao gồm chi phí không?

Có bảo hiểm thích hợp để chống lại việc mất dữ liệu là cực kỳ quan trọng, đặc biệt là đối với các giải pháp IoT thương mại. Câu trả lời cho câu hỏi đầu tiên (“Doanh nghiệp của bạn phải chịu tổn thất gì nếu bạn mất dữ liệu trong cơ sở dữ liệu của mình?”) Là hoàn toàn cụ thể cho doanh nghiệp của bạn — chỉ bạn mới có thể xác lập chi phí tổn thất kinh doanh.

Phần còn lại của các câu hỏi phụ thuộc vào sự lựa chọn và kiến ​​trúc cơ sở dữ liệu của bạn. Một kiến ​​trúc phù hợp sẽ đảm bảo rằng việc mất dữ liệu ít có khả năng xảy ra hơn. Nếu bạn đang mua cơ sở dữ liệu từ một nhà cung cấp, hãy xác minh thỏa thuận hỗ trợ và SLA của bạn. Nếu cơ sở dữ liệu thuộc về một cộng đồng mã nguồn mở, hãy đánh giá mức độ tích cực của cộng đồng và loại cộng đồng hoặc hỗ trợ thương mại nào bạn nhận được cho cơ sở dữ liệu của mình.

4. Chi phí hoạt động: Đây là một chức năng cho biết bạn cần bao nhiêu giờ người hoặc sức người để vận hành cơ sở dữ liệu của mình. Tự động hóa là câu thần chú để thành công. Cơ sở dữ liệu cung cấp các điều khiển tự động hóa để triển khai, phân vùng provi, chuyển đổi dự phòng, mở rộng quy mô, phân vùng dữ liệu, sao lưu, phục hồi, giám sát và cảnh báo, sẽ giúp bạn hoạt động hiệu quả.

Để đánh giá chi phí hoạt động dài hạn, bạn nên đánh giá chi phí khóa nhà cung cấp đám mây. Nếu cơ sở dữ liệu của bạn bị ràng buộc với một nhà cung cấp đám mây, thì sự gắn bó của bạn với nhà cung cấp của bạn sẽ phát triển khi dữ liệu của bạn phát triển. Cơ sở dữ liệu bất khả tri đám mây sẽ cho phép bạn chọn nhà cung cấp đám mây hiệu quả về chi phí nhất mà không phải chịu thêm chi phí di chuyển dữ liệu trong tương lai.

Kết Luận

Khi nói đến việc chọn cơ sở dữ liệu phù hợp cho giải pháp IoT thế hệ tiếp theo của bạn, bạn khá dễ bị lạc trong vô số cơ sở dữ liệu hiện có ngày nay. Tuy nhiên, nếu bạn chia giải pháp của mình thành các dịch vụ thành phần và hiểu nhu cầu cơ sở dữ liệu của chúng, bạn có thể thu hẹp các lựa chọn cơ sở dữ liệu của mình một cách hiệu quả. Hầu hết các giải pháp IoT có thể phụ thuộc vào dữ liệu nóng

Bài viết trên được biên soạn và chỉnh sửa bởi SmartFactoryVN.com . Các bạn sao chép xin ghi rõ nguồn bài viết.

Nguồn: smartfactoryvn.com

Bài viết 4 bước để lựa chọn đúng cơ sở dữ liệu cho giải pháp IoT của bạn đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.

Lean rất quan trọng đối với văn hóa của TestOil và mọi thứ chúng tôi làm. Nó cũng là chìa khóa cho lợi nhuận của doanh nghiệp của chúng tôi.

Lịch sử tinh gọn của TestOil

Chúng tôi bắt đầu sáng kiến ​​Lean vào năm 2015 với sự khuyến khích của người sáng lập kiêm Giám đốc điều hành Dan Richards. Mục tiêu ban đầu là giảm lãng phí và nâng cao hiệu quả. Trong ba năm tiếp theo, TestOil đã sử dụng, nhưng chưa bao giờ tận dụng hết sức mạnh của Lean. Năm 2018, Mary Messuti tham gia với tư cách COO; cô ấy bây giờ là chủ tịch.

Mary đến với TestOil với nền tảng Lean vững chắc. Bà đã chấp nhận và thăng chức Lean với tư cách là giám đốc điều hành cấp cao nhất tại các tổ chức toàn cầu trong hơn 20 năm. Tại mỗi công ty, bà đều cung cấp cho nhân viên cơ hội đạt được chứng chỉ Đai đen. Làm việc với những nhân viên này là một cách cô ấy giữ cho kỹ năng Six Sigma của mình luôn tươi mới.

Một trong những mục tiêu chính của Mary tại TestOil là làm sống lại sáng kiến ​​Lean của chúng tôi. Khi cô mới đến, TestOil đang trong quá trình tăng gấp đôi quy mô phòng thí nghiệm phân tích dầu của mình. Chúng tôi đang phát triển và muốn tăng chất lượng và tốc độ thông lượng. Để làm được điều đó, chúng tôi cần cải thiện hiệu quả không chỉ trong phòng thí nghiệm mà còn trong các lĩnh vực khác bao gồm CNTT, vận chuyển và hậu cần – luôn với mục tiêu chính là cung cấp giá trị tốt hơn cho khách hàng. Xây dựng Lean vào quy trình có nghĩa là mọi người sẽ có tiếng nói về cách nơi làm việc mới của họ sẽ được thiết kế.

Đào tạo

Đào tạo tinh gọn là một phần của quá trình giới thiệu. Chúng tôi cũng cung cấp dịch vụ huấn luyện và mời nhân viên tham gia ở mọi cấp độ và tham dự các sự kiện Lean. Các hoạt động Lean thường xuyên bao gồm thiết kế các thử nghiệm (DOE), các chu trình PDCA (lập kế hoạch, thực hiện, kiểm tra, hành động) nhanh chóng, thực hiện các cuộc dạo chơi gemba, các sự kiện Kaizen hàng quý, đồng thời xác định và phân tích các chỉ số hiệu suất chính (KPI) và các biện pháp đối phó sẽ thúc đẩy sự cải tiến.

TestOil giới thiệu mọi người trong tất cả các chức năng công việc về Lean Six Sigma (LSS) trong tuần đầu tiên tham gia. Tính đến cuối năm 2020, có năm Six Sigma Green Belts tại TestOil đại diện cho một loạt các chức năng công việc; tất cả đều được khuyến khích theo đuổi các chứng chỉ bổ sung.

Việc đào tạo liên tục đã diễn ra thông qua nhiều chương trình bao gồm các trường đại học, các lớp học trực tuyến và các chương trình nhân viên nội bộ. Tư cách thành viên của chúng tôi trong Hiệp hội AME (Hiệp hội Sản xuất Xuất sắc) Cleveland cũng là một thành phần quan trọng giúp chúng tôi có thể liên tục cải thiện với Lean.

Cách LSS hoạt động tại TestOil

Vào tháng 2 năm 2020, TestOil đã đưa tôi tham gia chương trình Lean của nó lên một cấp độ tiếp theo. Tôi đã làm việc với các sáng kiến ​​Lean từ năm 2016. Trước khi gia nhập TestOil, tôi đã phát triển bản đồ dòng giá trị và triển khai hoạt động Lean trong một công ty sản xuất khuôn nhựa. Tại TestOil, công việc của tôi là loại bỏ lãng phí, thắt chặt vòng lặp giao tiếp và cung cấp giá trị cho khách hàng càng nhanh càng tốt. Để đạt được điều này, tôi cố vấn cho nhân viên, thúc đẩy các nỗ lực cải tiến liên tục và thực hiện kế hoạch chiến lược Lean bao gồm các sự kiện Kaizen và các cuộc họp xuất sắc trong hoạt động.

Giá trị cốt lõi của TestOil bao gồm khách hàng là thượng đế, cải tiến liên tục, học hỏi, năng lượng và trách nhiệm. Tất cả những điều này đều được thể hiện trong Lean. Tinh gọn là một trong những lý do khiến nhân viên của chúng tôi cảm thấy được lắng nghe và biết rằng họ có tiếng nói trong việc làm cho công ty tốt hơn. Khi một quy trình được sắp xếp hợp lý, bảy chất thải Lean được giảm bớt và sản lượng công việc tăng lên.

Trong khi TestOil tôn trọng các cách tiếp cận khác nhau mà các tổ chức khác thực hiện để tiến hành cải tiến và giải quyết các vấn đề, Lean cho phép chúng tôi thấy rõ sự lãng phí trong quá trình này, xác định các kế hoạch cải tiến trong tương lai và phát triển một kế hoạch thực hiện hợp lý để giảm các hoạt động không mang lại giá trị gia tăng.

Lean đã mang đến cho chúng tôi văn hóa cải tiến liên tục giúp chúng tôi có thể phấn đấu và tạo ra những thay đổi tích cực. Văn hóa chấp nhận thay đổi không do dự và đơn giản hóa quy trình của chúng tôi tạo ra một nền văn hóa của sự nhiệt tình năng động.

Bộ phận Lean của chúng tôi đã định nghĩa “khách hàng” là tất cả mọi người làm việc tại TestOil, điều này cuối cùng được chuyển thành dịch vụ mà chúng tôi cung cấp cho khách hàng bên ngoài. Thông qua Lean, chúng tôi đã cải thiện dịch vụ của mình cho khách hàng bằng cách giảm thiểu và loại bỏ các quy trình không cần thiết trong phòng thí nghiệm ảnh hưởng đến việc hoàn thành kịp thời việc thử nghiệm mẫu dầu. Tích hợp Lean trong tất cả các bộ phận cho phép chúng tôi phấn đấu hướng tới một mục tiêu chung: Trở nên Nổi bật trên mọi phương diện.

Sự khác biệt LSS tiếp tục tạo ra tại TestOil

Lean tiếp tục giúp chúng tôi chống sai sót cho các quy trình của mình cũng như giới thiệu tự động hóa với sự tham gia của con người và tiến hành kiểm tra chất lượng tại nguồn để loại bỏ các lỗi trong giai đoạn đầu của quy trình. Ngoài ra, nó còn cho chúng ta thấy cách liên tục loại bỏ lãng phí.

Tầm nhìn Lean của chúng tôi là có các quy trình được tối ưu hóa hoàn toàn với tất cả các giá trị của chúng được xác định bởi một quy trình được kiểm chứng sai lầm. Chúng tôi sẽ tiếp tục hỗ trợ đầy đủ các trụ cột quản lý sản xuất tổng thể (TPM) cùng với jidoka (tự chủ) và just-in-time (JIT). Ngoài những công cụ đã được đề cập, chúng tôi đang sử dụng các công cụ LSS sau thường xuyên để hoàn thành mục tiêu của mình:

• Một ma trận để xác định sáu tổn thất lớn trong sản xuất
• Tiếng nói của khách hàng
• 5S liên tục
• Giới thiệu về trao đổi xúc xắc một phút (SMED) bất cứ khi nào có thể
• Thực hiện quy trình DMAIC (Xác định, Đo lường, Phân tích, Cải thiện, Kiểm soát)
• Một sự kiện Kaizen mỗi quý

Khi chúng tôi tiếp tục phát triển, mọi không gian làm việc mới sẽ được thiết kế theo nguyên tắc Tinh gọn. Đối với TestOil, Lean là một hành trình liên tục áp dụng những thay đổi và theo đuổi sự hoàn hảo – một nỗ lực không ngừng nhằm cải thiện con người và quy trình. Như Mary Messuti nói, “Bất cứ khi nào bạn triển khai Lean, bạn đang xây dựng chất lượng cho mọi thứ bạn làm.”

TestOil tiếp tục tiếp cận các vấn đề bằng cách loại bỏ các hoạt động không có giá trị gia tăng, giảm sự thay đổi trong các bước và đảm bảo không có chỗ cho lỗi giữa mỗi bước. Việc tích hợp tất cả tám trụ cột của TPM là mục tiêu mà chúng tôi đang thực hiện. Điều này sẽ đảm bảo mỗi quy trình được xác định rõ ràng và được lập thành văn bản. Nó cũng sẽ đảm bảo quản lý kiến ​​thức hoàn hảo và truyền tinh thần trách nhiệm về thiết bị cho mỗi thành viên trong nhóm.

Điểm mấu chốt là Lean là một hành trình liên tục áp dụng những thay đổi và theo đuổi sự hoàn hảo. Hành trình theo đuổi sự hoàn hảo này là để có được sức mạnh tổng hợp trong tổ chức của chúng tôi để cải thiện bằng cách hiểu nhu cầu của khách hàng, mục tiêu của công ty, quy trình quy trình và cơ hội loại bỏ lãng phí.

Thành công

Trong năm 2020, chúng tôi đã đạt được tiết kiệm chi phí $ 200,000 so với $ 89,000 trong năm 2019. Chúng tôi cũng lưu khoảng 70 dặm trong chuyển động bằng cách giảm dấu chân trong phòng thí nghiệm và khu vực văn phòng. Ngoài ra, chúng tôi đã tổ chức bốn sự kiện Kaizen vào năm 2020 để giải quyết các vấn đề và hợp lý hóa quy trình phát triển sản phẩm mới.

Bạn cũng có thể thích

Nguồn: www.isixsigma.com

Bài viết Tận dụng Lean Six Sigma để trở nên đáng chú ý đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.

Kiến trúc hướng sự kiện ( EDA – Event Driven Architecture ) là một mẫu thiết kế phần mềm cho phép tổ chức phát hiện “sự kiện” hoặc các khoảnh khắc kinh doanh quan trọng (chẳng hạn như giao dịch, lượt truy cập trang web, bỏ qua giỏ hàng, v.v.) và hành động theo thời gian thực hoặc gần thực thời gian. 

Mẫu này thay thế kiến ​​trúc “yêu cầu / phản hồi” truyền thống, nơi các dịch vụ sẽ phải đợi phản hồi trước khi chúng có thể chuyển sang tác vụ tiếp theo. Luồng của kiến ​​trúc hướng sự kiện được điều hành bởi các sự kiện và nó được thiết kế để phản hồi chúng hoặc thực hiện một số hành động để phản hồi lại một sự kiện.

Kiến trúc hướng sự kiện thường được gọi là giao tiếp “không đồng bộ”. Điều này có nghĩa là người gửi và người nhận không phải đợi nhau chuyển sang nhiệm vụ tiếp theo của họ. Hệ thống không phụ thuộc vào một thông điệp đó. 

Ví dụ: một cuộc gọi điện thoại được coi là đồng bộ hoặc nhiều hơn theo đường của kiến ​​trúc “yêu cầu / phản hồi” truyền thống. Ai đó gọi cho bạn và yêu cầu bạn làm điều gì đó, người yêu cầu đợi trong khi người trả lời hoàn thành nhiệm vụ và sau đó cả hai bên đều cúp máy. Một ví dụ về giao tiếp không đồng bộ sẽ là tin nhắn văn bản. Bạn gửi một tin nhắn và trong một số trường hợp, bạn thậm chí không biết mình đang gửi nó cho ai hoặc có ai đang nghe hay không, nhưng bạn không đợi phản hồi.

Sự phát triển của kiến ​​trúc hướng sự kiện

Trong vài năm qua, đã có một phong trào từ tập trung vào dữ liệu ở trạng thái nghỉ (kiến trúc hướng dịch vụ) sang tập trung vào các sự kiện (kiến trúc hướng sự kiện). Chúng tôi đang chuyển từ việc tích lũy dữ liệu và hồ dữ liệu sang tập trung vào dữ liệu trong chuyến bay và theo dõi nó trong khi nó đang di chuyển từ nơi này sang nơi khác. 

Theo truyền thống, hầu hết các hệ thống hoạt động theo mô hình mà bạn có thể nghĩ là mô hình trung tâm dữ liệu, nơi dữ liệu là nguồn chân lý. Việc chuyển sang kiến ​​trúc hướng sự kiện có nghĩa là chuyển từ mô hình trung tâm dữ liệu sang mô hình trung tâm sự kiện. Trong mô hình hướng sự kiện, dữ liệu vẫn quan trọng, nhưng các sự kiện trở thành thành phần quan trọng nhất. Trong khi trong mô hình mô hình hướng dịch vụ, ưu tiên cao nhất là đảm bảo bạn không mất bất kỳ dữ liệu nào. 

Với kiến ​​trúc hướng sự kiện, ưu tiên là đảm bảo bạn phản hồi các sự kiện khi chúng diễn ra. Bởi vì có một quy luật lợi nhuận giảm dần khi nói đến các sự kiện, chúng càng già đi, chúng càng ít giá trị hơn. Tuy nhiên, ngày nay, kiến ​​trúc hướng dịch vụ và kiến ​​trúc hướng sự kiện thường được sử dụng cùng nhau.

Kiến trúc hướng sự kiện thường sử dụng sự tương tự nhật ký để theo dõi mọi thứ. Các nhà phân tích nói về các sự kiện như những điều bất biến đã xảy ra. Và nếu bạn muốn tìm hiểu những gì đã xảy ra trong quá khứ, bạn có thể quay lại và phát lại nhật ký. 

Trong khi ở mô hình trung tâm dữ liệu, bạn chủ yếu tập trung vào trạng thái của dữ liệu như hiện tại. Và sau đó, phép loại suy cuối cùng mà các nhà phân tích sử dụng khi mô tả sự khác biệt giữa kiến ​​trúc lấy dữ liệu làm trung tâm và sự kiện là họ thường so sánh chúng giữa một kho thông tin và một hệ thống thần kinh mang thông điệp xung quanh doanh nghiệp.

Khi sử dụng kiến ​​trúc hướng sự kiện, bạn có các nhà sản xuất sự kiện tạo và gửi thông báo sự kiện và bạn có thể có một hoặc nhiều người nhận thông tin sự kiện, nơi việc nhận sự kiện sẽ kích hoạt logic xử lý. Ví dụ: giả sử Netflix vừa tải lên một bộ phim mới. Có thể có một số ứng dụng đang lắng nghe hoặc chờ đợi thông báo đó, sau đó kích hoạt hệ thống nội bộ của chính chúng để công bố thông tin của riêng chúng về sự kiện đó cho người dùng của chúng. Điều này khác với nhắn tin trả lời yêu cầu truyền thống ở chỗ các ứng dụng vẫn đang chạy và mặc dù chúng có thể đang lắng nghe sự kiện này nhưng chúng không bị tê liệt trong khi chờ đợi. Và, họ có thể trả lời khi tin nhắn được xuất bản. Do đó, nhiều dịch vụ có thể chạy song song.

Sự kiện là gì?

Một sự kiện được định nghĩa là sự thay đổi trạng thái của một số hệ thống kinh doanh chính. Ví dụ: ai đó mua một sản phẩm, ai đó đăng ký chuyến bay hoặc xe buýt đến nơi nào đó trễ. Và nếu người ta nghĩ về nó, các sự kiện tồn tại ở khắp mọi nơi và liên tục xảy ra, bất kể ngành nào. Chúng có sức lan tỏa trên mọi lĩnh vực kinh doanh. Điều này bao gồm bất kỳ điều gì tạo ra một thông điệp bằng cách được sản xuất, xuất bản, phát hiện hoặc tiêu thụ đều được coi là một sự kiện. 

Sự kiện tách biệt với thông báo, bởi vì trong khi sự kiện xảy ra, thông báo là thông báo di chuyển chuyển tiếp sự kiện. Trong kiến ​​trúc hướng sự kiện, một sự kiện có thể sẽ kích hoạt một hoặc nhiều hành động hoặc quy trình để đáp ứng với sự xuất hiện của nó. Ví dụ về một sự kiện có thể bao gồm:

• Yêu cầu đặt lại mật khẩu
• Một gói hàng đến nơi đã được chuyển đến nơi
• Kho hàng tạp hóa cập nhật hàng tồn kho của mình
• Một nỗ lực truy cập trái phép đã bị từ chối

Mỗi sự kiện này có khả năng kích hoạt một hoặc nhiều hành động hoặc quy trình để đáp ứng. Một phản hồi có thể đơn giản là ghi lại sự kiện cho các mục đích giám sát. Những người khác có thể là:

• Một email để đặt lại mật khẩu được gửi đến khách hàng
• Vé bán đã đóng
• Đặt hàng thêm rau diếp (hoặc bất kỳ nguyên liệu nào sắp hết)
• Tài khoản bị khóa và nhân viên an ninh được thông báo

Với kiến ​​trúc hướng sự kiện, khi một thông báo sự kiện được gửi đi, hệ thống sẽ nắm bắt được rằng điều gì đó đã xảy ra như thay đổi trạng thái đã xảy ra và chờ gửi câu trả lời cho bất kỳ ai yêu cầu, bất cứ khi nào họ yêu cầu. Ứng dụng đã nhận được thông báo đó có thể phản hồi hoặc chờ phản hồi cho đến khi xảy ra thay đổi về trạng thái mà nó đang chờ đợi.

Các ứng dụng được xây dựng dựa trên kiến ​​trúc hướng sự kiện cho phép các ứng dụng kinh doanh kỹ thuật số nhanh nhẹn, có thể mở rộng, theo ngữ cảnh và đáp ứng nhanh hơn.

Kiến trúc hướng sự kiện hoạt động như thế nào?

Các thành phần của kiến ​​trúc hướng sự kiện có thể bao gồm ba phần: nhà sản xuất, người nhận thông tin , nhà môi giới. Người môi giới có thể là tùy chọn, đặc biệt khi bạn có một nhà sản xuất và một người nhận thông tin duy nhất đang giao tiếp trực tiếp với nhau và nhà sản xuất chỉ gửi các sự kiện cho người nhận thông tin . 

Một ví dụ sẽ là một nhà sản xuất chỉ gửi đến cơ sở dữ liệu hoặc kho dữ liệu để các sự kiện được thu thập và lưu trữ để phân tích. Thông thường nhất trong các doanh nghiệp, bạn có nhiều nguồn gửi tất cả các loại sự kiện với một hoặc nhiều người nhận thông tin quan tâm đến một số hoặc tất cả các sự kiện đó.

Hãy xem một ví dụ. Nếu bạn là nhà bán lẻ, bạn có thể thu thập tất cả các giao dịch mua đang diễn ra tại tất cả các cửa hàng của bạn trên toàn thế giới. Bạn đang đưa chúng vào cấu trúc theo hướng sự kiện của mình để theo dõi gian lận, gửi chúng đến bộ xử lý thẻ tín dụng hoặc bất kỳ hành động nào cần xảy ra tiếp theo. Đối với một nhà sản xuất, bạn có tất cả các loại dữ liệu từ thiết bị của bạn để cho bạn biết các sự kiện như nhiệt độ và áp suất để bạn có thể theo dõi các sự kiện này trong thời gian thực và thực hiện các hành động như dự đoán lỗi hoặc lên lịch bảo trì, tùy thuộc vào những gì dữ liệu cho bạn biết .

Ưu điểm của việc sử dụng kiến ​​trúc hướng sự kiện

Nhiều ứng dụng hiện đại đang hỗ trợ nhanh chóng các kiến ​​trúc hướng sự kiện. Tại sao thế này? Họ cung cấp những lợi ích gì?

Kiến trúc hướng sự kiện là một cách tiếp cận kiến ​​trúc. Các ứng dụng được viết bằng bất kỳ ngôn ngữ nào trên bất kỳ nền tảng nào đều có thể sử dụng mẫu kiến ​​trúc này. Ở đây, chúng ta sẽ khám phá một số lợi thế của việc áp dụng kiến ​​trúc hướng sự kiện.

Sự tách biệt thực sự giữa Bên xuất bản sự kiện và người nhận thông tin

Hệ thống sử dụng kiến ​​trúc hướng sự kiện tách các thành phần trong hệ thống, phân tách quyền sở hữu dữ liệu theo miền. Sự tách rời này cho phép phân tách hợp lý giữa sản xuất và tiêu thụ các sự kiện.

• Bên xuất bản sự kiện không cần quan tâm đến việc các sản phẩm mà họ sản xuất sẽ được tiêu thụ như thế nào (vì vậy có thể thêm người nhận thông tin mà không ảnh hưởng đến Bên xuất bản sự kiện ).
• người nhận thông tin không cần quan tâm đến việc chúng được sản xuất như thế nào.

Do khớp nối lỏng lẻo này, các microservices có thể được thực hiện bằng các ngôn ngữ khác nhau hoặc sử dụng các công nghệ khác nhau và phù hợp với các công việc cụ thể. Do đó, việc mã hóa dữ liệu sự kiện không quan trọng – nó có thể là JSON, XML, Avro, v.v.

Việc tách các thành phần của một ứng dụng cũng cho phép chúng được chia tỷ lệ dễ dàng và độc lập với nhau trên toàn mạng. Các nhà phát triển có thể sửa đổi hệ thống của họ bằng cách thêm hoặc xóa động các nhà sản xuất sự kiện và người nhận thông tin mà không cần thay đổi bất kỳ logic nào trong bất kỳ dịch vụ vi mô nào.

Không một dịch vụ sản xuất nào cần biết về các dịch vụ tiêu thụ các sự kiện mà họ sản xuất. Tương tự, khi bất kỳ dịch vụ nào sử dụng thông điệp, họ chỉ cần đăng ký luồng sự kiện.

Trong sơ đồ ví dụ trên, chúng ta có thể dễ dàng thêm Dịch vụ Tài chính Taxi đăng ký các sự kiện Dịch vụ Xe Taxi và thu thập dữ liệu, có thể bao gồm mức tiêu thụ nhiên liệu. Với dịch vụ vi mô được bổ sung này, Dịch vụ xe taxi sau đó có thể đề xuất giá cước tốt nhất hoặc gửi các sự kiện mới về hiệu quả của tài xế, cả hai đều có thể được Dịch vụ đội xe taxi sử dụng như một yếu tố khi phân bổ tài xế cho các đơn đặt hàng.

Khả năng phục hồi

Sự kết hợp lỏng lẻo của các thành phần mà kiến ​​trúc hướng sự kiện cung cấp cũng có nghĩa là các dịch vụ không cần phải lo lắng về trạng thái hoặc sức khỏe của dịch vụ khác. Sự kết hợp lỏng lẻo này cung cấp một mức độ phục hồi trong hệ thống, vì vậy nếu một microservice bị hạ xuống, ứng dụng vẫn có thể tiếp tục chạy khi không có nó. Điều này đạt được nhờ các sự kiện được lưu trữ trong xương sống nhắn tin để dịch vụ tiêu thụ có thể nhận chúng khi nó phục hồi.

Mặc dù khả năng phục hồi không dành riêng cho các kiến ​​trúc hướng sự kiện, nhưng bản chất của cách các sự kiện đến mang lại một lợi thế bổ sung. Sự kiện là không đồng bộ, có nghĩa là các sự kiện được xuất bản khi chúng xảy ra. Các dịch vụ sử dụng các sự kiện dưới dạng một luồng không bị ràng buộc và chúng theo dõi nơi chúng đến. Vì vậy, nếu các dịch vụ bị lỗi, chúng có thể tiếp tục từ nơi chúng đến và nếu cần, phát lại các sự kiện có thể đã bị lỗi. Dịch vụ sản xuất không bị ảnh hưởng, nó có thể tiếp tục sản xuất các sự kiện. Điều này trái ngược với các kiến ​​trúc REST, là kiến ​​trúc đồng bộ, vì vậy các dịch vụ ngang hàng phải được thiết lập và logic thử lại phải được thực hiện để đối phó với các lỗi mạng.

Ví dụ: kiến ​​trúc hướng sự kiện có thể hữu ích trong các tình huống mà bạn có các thiết bị cạnh dễ chuyển sang chế độ ngoại tuyến. Sau khi các thiết bị cạnh quay trở lại, các sự kiện vẫn có thể được xử lý bởi ứng dụng khách. Ví dụ trong vận chuyển, chúng ta hãy xem xét các container vận chuyển thông minh. Công-te-nơ vận chuyển thông minh là công-te-nơ thu thập và phân tích dữ liệu đo từ xa về tình trạng của công-te-nơ và gửi dữ liệu tóm tắt trở lại trung tâm trung tâm theo khoảng thời gian đều đặn. Mạng thường có thể không đáng tin cậy trên tàu, vì vậy nếu bạn có một số container vận chuyển thông minh trên tàu và chúng hoạt động ngoại tuyến, khi chúng hoạt động trở lại, người nhận thông tin trên bờ vẫn có thể nhận được tin nhắn. Tương tự, nếu bạn có một số bản cập nhật cần được gửi đến biên từ trên bờ, chúng sẽ vẫn được nhận sau khi các dịch vụ biên hoạt động trở lại.

Bài viết trên được biên soạn và chỉnh sửa bởi SmartFactoryVN.com . Các bạn sao chép xin ghi rõ nguồn bài viết.

Nguồn: smartfactoryvn.com

Bài viết Kiến trúc hướng sự kiện (Event Driven) là gì ? đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.