主頁（http://www.by236.com）：從數字城市邁向智能城市

iCity是一個復雜的信息生態系統，其在每一時刻所擁有的大數據都是記錄城市社會生態系統的映像，折射出市政管理機構對城市的宏觀調控，以及市民競爭和市場機制對城市資源配置和發展作用的數字化描述。iCity連接的是數據，方便的是民生。

◎中國科學院院士、軟件開發環境國家重點實驗室主任李未/文

李未

北京航空航天大學計算機系教授、軟件開發環境國家重點實驗室主任、中國科學院院士、國務院學位委員會委員。在實用并發語言語義、并發語言的翻譯理論等方面具有開創性研究成果，曾獲國家自然科學二等獎、何梁何利科技進步獎等多項獎勵。

過去10年，“數字城市”、“大數據城市”、“智能城市”和“智慧城市”等成為學術界、各種先鋒論壇和社會媒體熱議的話題。一般而言，一個行業或一個區域的信息化過程可分為兩個階段，第一個階段是數字化，又稱數字城市（以下簡稱dCity，即Data City），它包括信息的傳感、存儲、計算、傳輸和控制的網絡化和數字化；第二階段是智能化，是數字化的更高階段，又稱智能城市（以下簡稱iCity，即Intelligent City）。

以下擬從數字城市的智能轉型這個角度，探討智能城市必須提供的幾種服務，以及為實現這些服務在軟件工程實現方面需要采取的措施和方法。

看病問診的深度查詢

我們先通過一個例子說明什么是深度查詢，然后再來看怎樣開發和使用這種查詢。如果我們向Google輸入：“我經常惡心、頭痛、有時嘔吐，看東西不清楚，偶爾出現耳鳴，我該怎么辦？”Google把“頭痛、惡心、嘔吐”等作為關鍵詞，查出約42900個網頁中出現了上述關鍵詞。我們在贊嘆Google的效率的同時，卻無法稱之為“智能服務”，因為我們最關心的問題：究竟“我”得了什么病？應該怎么治？并沒有得到像朋友、更不用說像看醫生那樣直截了當和有建設性的回答。

下面，讓我們仿照病人去醫院看病的過程，設計一個簡單的“深度查詢”的例子。這個查詢過程由下述4步組成：

初診導醫

病人向iCity輸入癥狀或感覺：“頭痛、惡心、嘔吐、耳鳴和怎么辦”，希望iCi t y通過分析這些感覺和癥狀，向用戶提供相當于初診醫生做出的對疾病的初步診斷和建議（見圖）。iCity應該向病人提供有上述病癥表現的主要疾病名稱，即“腦部腫瘤、美尼爾氏癥、頸椎病或胃腸感冒”。病人從4種病中選擇了其中一種，例如“腦部腫瘤”，并將其輸入iCity，這種行為稱為關聯選擇或關聯推理，因為iCity把4種不同但又有共同病狀的“實體”關聯起來。

方案推薦

由兩部分組成，即先做關聯，再做邏輯推理。首先，在病人做出初診選擇后，iCity的反應是：推薦3種治療預案，即治療藥物推薦、腫瘤醫院推薦、腫瘤專家推薦。iCity又把3種“本體”關聯起來，而用戶再做一次關聯選擇，例如選擇腫瘤醫院。接著，選擇中國醫學科學院腫瘤醫院，這次iCity做的是邏輯推理，是全局到個體的推理，因為中國醫學科學院腫瘤醫院是一所腫瘤醫院。

就醫服務

用戶選擇中國醫學科學院腫瘤醫院之后，iCity提供該醫院的所有就醫服務，包括：掛號預約程序、醫療費用評估、就醫智能導航、氣象出行建議。病人再做一次關聯操作，例如“掛號預約程序”，完成第3次人機交互。

數據鏈接

計算機提供中國醫學科學院腫瘤醫院網上掛號預約的全套程序。

一般而言，深度查詢是系統從描述事物的現象、癥狀或印象開始，通過人機交互的方式，提供與現象或癥狀相關的可供選擇的概念或實體。在用戶做出選擇后，系統根據云計算環境中存儲的本體和相關知識圖譜，在與用戶逐步深入的交互中，通過歸納猜想、邏輯推理和關聯操作，最終提供用戶所需要的、網上能查到的、與改善現狀關聯的所有知識和數據。從這個角度來看，著名的TuringTest 是深度查詢的一個特例。總之，深度查詢的推理和操作的基礎理論框架應包括：

（1）歸納猜測：屬性到實體；

（2）關聯演算：實體間選擇；

（3）邏輯推理：共性到實例；

（4）數據鏈接：實體到數據（知識卡片）。

而實現“深度查詢”服務的解決方案應該包括：建立描述各種非結構化數據的元語言模型，即構建數據的一體化表示和組織，構建包含本體、實體、知識圖譜和知識卡片的非結構化數據云，建立實體與原始數據的鏈接，以及實現歸納猜想、關聯操作、邏輯推理的關于知識的計算框架和推理機制等。

在大數據時代，人類五官的感受已經由現代傳感器產生的大數據所代替。所以，定律發現的任務就是從傳感器接收到的大數據中，精煉出基本概念和這些概念之間精確的數學關系，也就是歸納出謂詞和謂詞之間的數學方程式。在社會科學和人類社會大數據環境下，這些概念的關系可以是因果關系，也可以是關聯關系。

從天通苑智能交通看決策生成

讓我們通過一個例子來說明什么是智能城市的決策生成。

北京天通苑地區約有8平方公里，人口91.5萬。早高峰期間約有14萬人要乘坐公交車進城上班，而主要進城之路只有2條，一條是經回龍觀再繞行G6高速路進城，另一條是先經立湯路再到安立路進城。當前要解決的問題是：公共交通擁堵、公交車超載、安全性和舒適性差、路上消耗時間長。

天通苑實際公交需求是：如果每車70人，每人乘車時間不超過40分鐘到達目的地，早6:00至9:00間需要平均每分鐘發出10輛公交車，共需約2000車次，長度近40公里。

在當前數字化城市環境下，經大數據搜集和統計計算的結果是：居民出行通往北京38個區域，但只有9個區域是主要目的地，占乘客總量的83%。

提出問題：如果用戶向百度輸入：“天通苑地區上班時間，交通擁堵，乘公交車，進城，尋求解決方案”，百度當下提供的服務，還不能給出對每個上班的用戶具體、可操作的建議，還不能說是智能服務。人們心目中具有智能的解答應該由下述幾步組成：

決策定性：當用戶向iCity輸入“天通苑早晨交通擁擠，尋求解決方案”時，希望得到對方給出既“高屋建瓴”又“符合邏輯”的回答。所以，iCity的回答是一個問句：需要“應急方案”還是“長期方案”？這是一種歸納推測，因為這是從具體方案到方案類型的行為。

當用戶選取“應急方案”時，他或她進行了一次關聯操作或關聯推理，而iCity是把兩種不同類型的求解方案關聯起來。這種關聯是由計算機提供的，而選擇是用戶（人）做的，對計算機而言，這是第一次人機交互。

方案推薦：在用戶做出方案分類選擇后，iCity的應對是：提出4類應急解決方案供用戶選擇，包括“公交車調度優化”、“熱點區域直達”、“乘車時間優化”和“繞行路線安排”。iCity把4種應急方案關聯起來，而用戶再做一次選擇，如：“乘車時間優化”。完成第二次人機交互。

方案選擇：用戶選擇“乘車時間優化”后，由于在大數據和云計算環境下，互聯網上存有天通苑14萬進城上班族每個人的姓名、身份證號、住址、手機號、當前GPS地址、工作單位地址、上班時間統計記錄等所有必要信息和數據，又擁有天通苑地區所有公交車的GPS地址、行車路線、車內乘客人數現狀的信息。這些數據和它們之間的關系組成了一個動態規劃系統，而iCity要解決的是大數據動態規劃問題。在云計算環境下，iCity可以直接或者請求用戶選擇求解方法、調用求解程序，得到可行決策。這包括：每一位上班族個人都將從手機上收到iCity 對個人的出行建議，例如，何時乘哪路公交以及換乘建議。當用戶同意后，iCity 還將把上班調整時間信息發給所在工作單位，以便調整當日上、下班時間。iCity還將把在均衡狀態下公交車的開車路線和時間等有關信息通知到每位公交司機。

從上述實例，我們可以得出以下關于iCity決策生成的一個宏觀描述：

iCity針對用戶的要求和問題，通過人機交互的方式對本體、實體、概念、屬性等多層次歸納猜想、邏輯推理、關聯操作，在與用戶的交互過程中，揭示問題的性質，提供與問題相關的所有可供選擇的決策類型。在用戶做出選擇后，iCity確定滿足用戶要求的問題求解數學模型，并通過逐步深入的人機交互，確定求解模型所需的邊界條件和初值。之后，iCity調用求解程序，根據用戶需求，提供群體的統計規律和群體的動態演變過程，并根據群體中每一個個體的個性化要求，給出針對個體的解決方案，做到群體均衡、個體優化。在群體和個體的解決方案實施后，iCity還將實時感知并驗證解決方案的實施效果，及時進行動態調整。統一數據模型勢在必行

城市的大數據是城市人群自然與社會知識和信息的數字映像，是通過各種數字化傳感裝置搜集的，來自于城市的各個角落和不同的人群。它們可以是結構化的（如傳統的數據庫文件），也可以是非結構化的（如語音、圖片和視頻等），而且來源于不同的歷史階段。由于社會發展的不均衡，從各種途徑獲得的原始數據的格式不統一，進而增加了數據處理的難度，降低了數據處理的效率。

發展到建設iCity 這一歷史階段，建立統一的數據模型已經勢在必行。這個數據模型應該具有下述性質：

首先是統一性，即它能夠以統一的模式描述各種結構和非結構類型的數據；二是集成性，即直接繼承和采用已有的關于各種類型數據的成熟處理技術；三是關聯友好性，它支持多源數據特征關聯操作；四是可擴展性，即支持數據規模擴展并保持處理效率；五是演化性，即以文本序列的方式記錄數據的演化；最后是傳感友好性，即這種數據模型可以嵌入到各種傳感器中，成為傳感器從外界接收的原始數據的存儲格式。這樣做的優點是可以充分發揮數字化傳感器的潛能，大大提高非結構化大數據的處理效率。

iCity是一個群體軟件工程

城市是一個復雜的社會生態系統，其組成和演化的基本特征是：在“宏觀層面”上，市政管理機構通過制定政策和發布法令，對城市的規劃和資源的配置進行宏觀調控；在“微觀層面”上，市民通過競爭和市場機制對城市資源配置和城市發展起著基礎或決定性作用。從這個角度來看，iCity則是一個復雜的信息生態系統，其在每一時刻所擁有的大數據都是記錄城市社會生態系統的映像，折射出市政管理機構對城市的宏觀調控，以及市民競爭和市場機制對城市資源配置和發展作用的數字化描述。

如果使用iCity 時特指其軟件系統，那么群體軟件工程應該是研制、開發和維護iCity的首選工程方法。如果我們把微軟公司研制Windows系統的方法稱為傳統軟件工程方法，那么傳統軟件工程方法在研發iCity時將面臨嚴峻挑戰。

以WindowsVista為例，軟件開發工作量約為：功能模塊約60000個，總代碼量6000萬行，投入9000名專業開發人員，耗時5年完成全部開發任務。然而這種傳統軟件工程方法受到iCity這類軟件的嚴峻挑戰，因為從整體的角度看，后者的規模和開發工作量將遠超過WindowsVista！

近幾年蘋果公司組織的AppStore和谷歌公司組織的AndroidMarket給我們帶來了激發社會群體廣泛參與軟件開發的新啟示。如果采用AppStore或Android Market的模式投入70萬人，iCity約5年就能建成！上述這兩個在軟件開發行業有歷史意義的事件告訴我們：采用開源代碼，選取眾包這種基于市場競爭的群體開發模式，將是解決iCity這類超大軟件生態系統研發、維護和演化問題的一個正確選擇。

綜上所述數字城市的智能轉型當前的主要任務是提供“深度查詢”、“規律發現”和“決策生成”3種應用服務，為此，有必要從數字傳感階段開始推進非結構化數據的統一模型，并采用群體軟工程件的方法，先從數字化城市比較成熟的行業作為試點開始做起。