Ở mọi nơi trên đất nước và trên toàn thế giới, các nhà lãnh đạo đang  cố gắng  làm cho các thành phố của họ “thông minh hơn”. Các dự án này thường đáp ứng các nhu cầu cụ thể và đang diễn ra – chẳng hạn như bãi đậu xe, quá tải, tiếng ồn và ô nhiễm – trong khi những dự án khác đã bắt đầu hướng đến các mục tiêu rộng lớn hơn – chẳng hạn như giảm tiêu thụ năng lượng, cải thiện lưu lượng giao thông hoặc tính bền vững. Nhưng như thường lệ với những ý tưởng vĩ đại, nhiều người đang áp dụng cách tiếp cận sai lầm. Chỉ đơn giản là không thể, trong một lần quét, để xây dựng Thành phố Thông minh. Giống như internet và web chưa hình thành đầy đủ, như thể từ một “kế hoạch tổng thể” nào đó, thì Thành phố Thông minh phải được xây dựng như những phần hữu cơ, độc lập và được kết nối với nhau. Như Stewart Brand lập luận một cách đồng tình, ngay cả các tòa nhà cũng phải học  theo từng bước.

Lộ trình Thành phố Thông minh là vô giá, đưa ra định hướng giúp đặt ra các kỳ vọng. Tuy nhiên, nó không nên xác định các công nghệ xuyên hệ thống cụ thể và chi tiết thực hiện, cũng như lập kế hoạch cho tất cả các dự án để khởi động hoặc hoàn thành đồng thời. Thay vào đó, chúng phải được tạo thành các giải pháp riêng biệt cho từng vấn đề, sau đó kết hợp với nhau theo các tiêu chuẩn mở và Giao diện lập trình ứng dụng mở   (API) và mỗi giải pháp được xây dựng như một dịch vụ độc lập. Đó là cách chúng phải phát triển nếu chúng ta muốn chúng thành công – học bằng cách lặp đi lặp lại.

Vấn đề hôm nay

Trong quá trình gấp rút “đánh chiếm thị trường”, các công ty đang bán “tầm nhìn hoàn chỉnh” – mặc dù các giải pháp chưa hoàn thiện – về cách hệ thống của họ có thể giải quyết các tệ nạn đang hoành hành trong thành phố hiện đại. Các nhà quy hoạch Thành phố thông minh, các nhà quản lý và quan chức bán tín bán nghi rằng các công ty này có một loại viên đạn bạc nào đó, trong một giải pháp duy nhất, tích hợp tất cả các chức năng của thành phố và nâng cao năng lực của họ, do đó làm cho họ làm việc cùng nhau một cách hiệu quả. Nhưng điều này cho thấy bản chất thực sự của vấn đề: không ai trong chúng ta đủ thông minh để đánh giá đầy đủ hoặc hiểu được sự phức tạp của việc quản lý tất cả các chức năng giúp một thành phố hoạt động. Sự đa dạng tuyệt đối của các hệ thống đảm bảo rằng không có công nghệ đơn lẻ nào có thể được áp dụng làm “giải pháp”. Ngoài ra, khung thời gian để thực hiện các chương trình khác nhau này có thể rất khác nhau, có nghĩa là công nghệ được chọn khi bắt đầu một dự án có thể sẽ bị lỗi thời khi bắt đầu một dự án khác.

Tệ hơn nữa, các công ty này cũng đang bán và triển khai các sản phẩm dựa trên các hệ thống độc quyền, khép kín. Chúng bao gồm radio độc quyền, phần cứng cho một mục đích, phần mềm và giao thức độc quyền cũng như các cổng và ứng dụng web đóng. Những thiết kế này hạn chế sự đổi mới và cản trở khả năng tương tác giữa các hệ thống mới hơn và cũ hơn, thường gắn chặt cái mới với những hạn chế của quá khứ. Điều này giống như Trojan Horse – một giải pháp yêu cầu tất cả các hệ thống trong tương lai phải sử dụng các hệ thống độc quyền này và do đó khóa thành phố vào nhà cung cấp cụ thể đó trong suốt thời gian còn lại của họ, hạn chế lựa chọn thiết kế và công nghệ cũng như kìm hãm sự đổi mới và áp dụng công nghệ mới hơn.

Nó không phải là tất cả u ám và diệt vong. Với việc áp dụng các hệ thống mở và triển khai kiến ​​trúc hướng dịch vụ, công nghệ trong tương lai có thể được xây dựng để tích hợp liền mạch hơn với các khoản đầu tư công nghệ trước đó.

Chọn một con đường khác

Chúng tôi đã học hỏi từ cộng đồng Lean-nhanh nhẹn để xây dựng thành công trong các bước nhỏ, gia tăng chứ không phải là một bước nhảy vọt. Nhưng với những nhu cầu, mô hình thiết kế và khung thời gian khác nhau, làm thế nào để có thể hoàn thành việc xây dựng Thành phố Thông minh trong những bước nhỏ? Nó được thực hiện bằng cách tận dụng bản chất của chính internet, hoàn chỉnh với các tiêu chuẩn mở và API mở. Bằng cách tách rời mọi hệ thống và loại bỏ các giao diện ẩn, chúng tôi có thể giảm bớt áp lực về thời gian và sự phụ thuộc lẫn nhau của công nghệ, do đó cho phép đổi mới nhiều hơn trong từng dự án riêng biệt trong khi “kiểm chứng trong tương lai” các quyết định thiết kế.

Chúng tôi sử dụng các vật liệu và kiến ​​trúc khác nhau để xây dựng các tòa nhà với các mục đích khác nhau (bệnh viện so với nhà ở so với nhà cao tầng), nhưng có một sự nhất quán ngay cả trong các tòa nhà khác nhau này đối với các kết nối điện và hệ thống ống nước tiêu chuẩn. Các dự án Thành phố thông minh có thể áp dụng mô hình thiết kế tương tự này. Điều này có nghĩa là đối với một dự án bãi đậu xe, thành phố có thể chọn công nghệ truyền thông thích hợp nhất nhưng yêu cầu hệ thống phải được xây dựng trên các giao thức tiêu chuẩn mở làm nền tảng cho internet (ví dụ: HTTP, IP, TCP và  MQTT ), sử dụng các định dạng dữ liệu như dưới dạng JSON hoặc XML và có các API mở.

Lớn hơn tổng các phần

Thay vì một Thành phố Thông minh hoàn chỉnh đã được hình thành trong nhiều thập kỷ, các nhà quản lý thành phố có thể tìm kiếm “điểm thấp” hoặc “điểm đau lớn nhất” và nhanh chóng hơn xây dựng một giải pháp quan trọng, biết rằng nó có thể đơn giản được kết nối với bất kỳ hệ thống nào trong tương lai một cách có thể mở rộng và an toàn. Hệ thống đỗ xe thông minh cho các đường phố hoặc ga ra đỗ xe được xây dựng bằng  LoRa  ngày nay có thể được kết nối với hệ thống quản lý giao thông thành phố được xây dựng bằng  NBIoT  vào năm tới, miễn là cả hai đều sử dụng API mở và tránh các giải pháp độc quyền, khép kín bao gồm các giải pháp đám mây “ khu vườn có tường bao quanh ” .

Dự án cải thiện thành phố tiếp theo – ví dụ như hệ thống đèn đường thông minh – có thể yêu cầu một công nghệ giao tiếp hoàn toàn khác với hệ thống đỗ xe trước đó. Đèn đường ở trên cao và phân bố nhiều hơn mét đỗ xe hoặc chỗ đỗ xe trong ga ra. Đèn đường có nguồn, trong khi cảm biến đỗ xe có thể sẽ hoạt động bằng pin. Các yêu cầu khác nhau này đòi hỏi phải sử dụng các công nghệ truyền thông khác nhau, nhưng cả hai hệ thống đều có thể được kết nối với nhau thông qua các giao thức và API chung. Thông qua các API mở, sự liên kết này không cần phải được thiết kế ngay từ đầu nhưng có thể được thêm vào sau khi từng hệ thống riêng biệt được cài đặt.

Ví dụ: hệ thống đèn đường được lắp đặt hôm nay có thể được kết nối với cảm biến lưu lượng giao thông được lắp đặt vào ngày mai. Hai hệ thống có thể sử dụng công nghệ truyền thông và bộ giao thức hoàn toàn khác nhau. Sự kết hợp mới này – đèn đường và cảm biến lưu lượng giao thông được kết nối thông qua các API mở – có thể cung cấp một giải pháp sáng tạo để giảm mức sử dụng năng lượng của đèn đường bằng cách làm mờ đèn khi không có ô tô, nhưng tăng độ sáng trước khi ô tô đến dựa trên các thông báo từ hệ thống phân luồng giao thông .

Việc sử dụng và tuân thủ các API mở và dịch vụ vi mô mang lại một lợi ích khác –  tốc độ tách rời . Điều này có nghĩa là ngay cả các dự án đồng thời cũng có thể được xây dựng ở các tốc độ khác nhau và triển khai vào các thời điểm khác nhau nhưng vẫn được kết hợp khi mỗi dự án được hoàn thành và hoạt động. Như trong ví dụ trên, dự án đèn đường thông minh có thể mất nhiều thời gian hơn để triển khai vì số lượng thiết bị tuyệt đối. Các cảm biến lưu lượng giao thông có thể được lắp đặt sớm hơn ở đâu. Các API mở giải phóng mỗi hệ thống khỏi sự phụ thuộc lẫn nhau về thời gian và tốc độ triển khai.

Khóa nhà cung cấp và bảo vệ trong tương lai

Một lợi ích khác của các tiêu chuẩn và API mở là loại bỏ khóa nhà cung cấp, đó là khi nhà cung cấp giành được tất cả các hoạt động kinh doanh trong tương lai vì một mình họ đang nắm giữ chìa khóa của thiết kế và dữ liệu. Nhà cung cấp khóa chặt sự đổi mới: bạn chỉ sáng tạo như những gì mà nhà cung cấp muốn trở thành hoặc cho phép bạn trở thành. Nếu một thành phố cần một thiết kế hoặc giải pháp không có trong danh mục đầu tư hiện tại của nhà cung cấp, thì sự lựa chọn của thành phố sẽ trở nên chờ đợi, trả thêm tiền để nhà cung cấp thêm nó vào lộ trình của họ hoặc đi ra ngoài hệ sinh thái và sử dụng một số loại cổng (trừ các cổng là  ác , xem dưới đây) để dịch các giao thức và các dữ liệu và kết nối các hệ thống.

Thay vào đó, các tiêu chuẩn và API mở mang lại khả năng kết hợp và phát triển với các công nghệ và hệ thống mới hơn. Tuy nhiên, giống như khóa của nhà cung cấp, bạn có thể gặp phải vấn đề về khóa công nghệ. Hãy tưởng tượng bạn đã xây dựng một dự án Thành phố thông minh yêu cầu sử dụng băng video và bây giờ không thể áp dụng công nghệ phát trực tuyến vì chúng không tương thích. Công nghệ thay đổi nhanh chóng; chỉ trong vài năm, chúng tôi đã chuyển từ 2G sang 3G và bây giờ là 5G trong môi trường di động. Bằng cách sử dụng các tiêu chuẩn mở để tách các giao thức lớp cao hơn khỏi các lớp thấp hơn, công nghệ có thể phát triển và các hệ thống sử dụng công nghệ cũ hơn có thể dễ dàng kết nối với nhau. Bằng cách này, một hệ thống được triển khai sử dụng 4G ngày hôm nay có thể tương thích với các hệ thống 5G vào ngày mai và các hệ thống 6G và 7G trong một vài năm nữa.

Nền tảng của sự đổi mới

Tránh khóa nhà cung cấp và công nghệ là rất quan trọng để cho phép đổi mới. Sẽ không có gì bất lợi cho cơ sở hạ tầng và tương lai của thành phố hơn là bị ràng buộc với một nhà cung cấp và phải xin phép để nâng cao hoặc mở rộng chức năng của hệ thống. Khi công nghệ mới xuất hiện trên thị trường và các dịch vụ mới được đưa ra để giải quyết các vấn đề khác của thành phố, khả năng nhanh chóng kiểm tra và kết nối chúng với các giải pháp hiện có là điều cần thiết để đưa ra các giải pháp phát triển và mang lại nhiều cơ hội đổi mới và giảm chi phí. Khi bạn bắt tay vào dự án tiếp theo của mình, hãy hỏi các nhà cung cấp của bạn – “bạn có sử dụng các giao thức chuẩn mở không?” và “các API và dữ liệu của bạn được xuất bản như thế nào?”

Tránh những cái bẫy này – cửa ngõ “xấu xa” và “đám mây riêng tư”

Một công cụ mà nhiều nhà cung cấp cố gắng tận dụng để thể hiện tính cởi mở và khả năng tương tác là “cổng vào”. Họ tuyên bố rằng họ cung cấp hoặc có thể xây dựng một cổng kết nối với các hệ thống khác. Cổng là một cái bẫy không bao giờ kết thúc ở rất nhiều cấp độ:

• chúng là một điểm thất bại duy nhất;
• chúng là một điểm tấn công duy nhất của tin tặc;
• chúng đòi hỏi sự phối hợp phức tạp giữa các hệ thống;
• bảo trì và cập nhật là tốn kém hoặc không tồn tại;
• cập nhật cần được quản lý;
• họ thêm chi phí cho phần cứng và điện năng; và
• chúng  đóng cửa và độc quyền.

Cái bẫy thứ hai là những đám mây riêng và những khu vườn có tường bao quanh. Nhà cung cấp sẽ tuyên bố rằng họ sử dụng “tất cả các tiêu chuẩn internet mở”, liệt kê giao thức này đến giao thức khác, nhưng họ chỉ sử dụng các giao thức này để gửi dữ liệu (  dữ liệu của bạn ) vào một hệ thống đám mây độc quyền, khép kín – khóa nó lại để chỉ họ có chìa khóa. Điều này tương tự như việc xây dựng một con đường dẫn đến một cống ngầm, bị chặn bởi một cổng khóa chỉ cho phép giao thông vào. Sau đó, các hệ thống mới phải được xây dựng để kết nối qua đám mây này, có thể là thông qua các giao diện kín và độc quyền. Cuối cùng, chỉ các hệ thống khác trong hệ sinh thái khép kín này mới có thể được sử dụng cho các dự án trong tương lai, do đó hạn chế sự đổi mới và tăng thời gian và chi phí. Gửi dữ liệu lên đám mây không phải là thuốc chữa bách bệnh, như nhiều nhà cung cấp muốn đề xuất.

Ai sở hữu dữ liệu – tức là dữ liệu CỦA BẠN

Trong các dự án Thành phố Thông minh, các mục tiêu cải thiện dịch vụ hoặc cơ sở hạ tầng của thành phố là động lực hàng đầu để thực hiện nhưng lợi ích lớn nhất sẽ đến từ sự sẵn có của dữ liệu thu thập được từ các dự án này và các hệ thống mới. Thật không may, nhiều hệ thống Thành phố Thông minh đang được cung cấp ngày nay đã khóa quyền truy cập vào dữ liệu trong các khu vườn có tường bao quanh, như đã đề cập trước đây. Dữ liệu bắt buộc phải được gửi đến các máy chủ do thành phố sở hữu và quản lý, hoặc hồ dữ liệu của thành phố   hoặc có sẵn mà không cần giấy phép thông qua các API mở. Chỉ bằng cách này, thành phố và các dự án Thành phố Thông minh trong tương lai mới có thể sử dụng và tận dụng nguồn thông tin phong phú và giá trị thực cơ bản của các loại dự án này.

Một mối quan tâm liên quan xung quanh quyền sở hữu dữ liệu là quyền sử dụng và bán dữ liệu được tạo ra bởi dự án Thành phố Thông minh – một loại hàng hóa có giá trị. Trong suốt vòng đời của dự án, cần rõ ràng rằng thành phố sở hữu TẤT CẢ CÁC QUYỀN đối với dữ liệu. Nhà cung cấp không được truy cập, phân phối hoặc bán bất kỳ dữ liệu nào dù ở dạng thô hay được tổng hợp mà không có sự cho phép rõ ràng của thành phố. Chỉ bằng cách này, bạn mới có thể bảo vệ các quyền và sự riêng tư của thành phố và của công dân.

Lựa chọn dự án phù hợp

Bằng cách áp dụng các tiêu chuẩn và API mở, giờ đây bạn có thể bắt tay vào dự án Thành phố thông minh mà không cần phải giải quyết tất cả các dự án thành phố khác cùng lúc hoặc hạn chế chúng với các lựa chọn được đưa ra ngay hôm nay. Nhưng việc lựa chọn dự án “phù hợp” là điều quan trọng. Trong một số trường hợp, cần thận trọng khi chọn một dự án nhỏ, nhanh chóng, chi phí thấp. Điều này cho phép bạn chân ướt chân ráo, thử nghiệm các nhà cung cấp, hoàn thành một dự án trong thời gian ngắn và hy vọng thành công; nhưng nếu bạn thất bại, hãy nhanh chóng thất bại, học hỏi và tiếp tục. Mặc dù vậy, đôi khi có một vấn đề với những dự án này: chúng có thể có ít tác động và chúng có thể khiến người khác nhìn chúng là “ho hum”.

Một giải pháp thay thế là chọn một dự án là “điểm đau” lớn của thành phố. Theo định nghĩa, những dự án này có tầm nhìn và tác động lớn, nhưng có thể có rủi ro lớn hơn nhiều và mất nhiều thời gian hơn để hoàn thành. Nhìn chung, chúng không đáp ứng các quy tắc về tinh gọn nhanh, nhưng các dự án “an toàn” nhỏ có thể không cho thấy những lợi ích thực sự mà Thành phố thông minh có thể mang lại. Giải quyết điều này bằng cách sử dụng chia và chinh phục. Thay vì triển khai bãi đậu xe thông minh trên toàn bộ thành phố, hãy chọn tập trung vào khu vực thành phố đặc biệt tắc nghẽn hoặc cấu trúc bãi đậu xe đơn lẻ.

Xây dựng thành công

Khi một thành phố đang trở nên thông minh hơn bằng cách đầu tư vào dự án Thành phố Thông minh, hãy sử dụng danh sách kiểm tra này để đánh giá dự án:

• Nó có bắt đầu quy mô nhỏ và tốt không? Điều này tốt hơn so với một giải pháp nguyên khối đòi hỏi một khoản đầu tư lớn.
• Có phải nó đang nhốt thành phố vào các công nghệ, hay thậm chí tệ hơn là các nhà cung cấp? Nó có loại trừ các nhà cung cấp khác không?
• Nó mở rồi? Những giao thức nào được sử dụng? Các API có được xuất bản và mở không?
• Nhà cung cấp có đề cập hoặc yêu cầu các cổng (xấu) không?
• Nó có giải quyết được một vấn đề nào đó cho thành phố một cách nhanh chóng, dù chỉ là một vấn đề nhỏ?
• Thành phố sẽ học hỏi được gì khi thực hiện dự án này?
• Ai sở hữu dữ liệu?

Thông qua việc áp dụng nghiêm ngặt và yêu cầu về tính mở, dự án Thành phố Thông minh của bạn có thể được thực hiện theo cách nhanh chóng, có lợi, có thể phát triển và có thể mở rộng. Các thành phố của chúng tôi có thể và sẽ trở nên thông minh hơn và nơi tốt hơn để sống qua các bước nhỏ và các tiêu chuẩn mở – API mở và  microservices  là stepping đá nền tảng cho tương lai đó.

Nguồn: https://www.iiot-world.com