輔助繪圖工具的方案選擇過程是複雜的，從去年8月底就開始了初步的調用，也經過了種種碰壁，最終得出了基本的方案。
先說一些題外話：爲什麼需要輔助繪圖設計？加班的龐大工作量來自於哪裏？
單位目前主營業務是地鐵信號系統工程總承包，包括地鐵新建及改造項目工程管理、系統設計、產品研發、系統集成、測試驗證等一整套解決方案和服務。未來的集成方案規劃爲中心、地面、車載。不管哪個子系統都不可避免的需要設計繪圖工作，由繪圖生成各個子系統的元數據，根據這些元數據進行代碼的數據配置工作。不同的城市不同的線路分別進行不同的設計繪圖、數據生成、數據配置等等工作，由此可想象到裏面的工作量。然而這種加班並沒有創造新的價值也沒有帶來新的利潤。
企業在未來要想更好的生存，就必須贏得更多的利潤，更少的加班成本。這樣一個良好的輔助繪圖工具設計，一個優秀的數據配置設計的需求就非常的強烈。開發更好用的設計、繪圖軟件，需求一變操作軟件馬上可以把成果弄出來。
話說輔助繪圖輔助數據配置工具如何設計呢？
輔助繪圖的關鍵在於：設計數據-圖元映射關係，因此所作的方案調研之中該方向就是核心訴求。最終的方案趨向於基於objectArx的二次開發。
基於objectArx的二次開發，該類庫爲C#專用類庫。ObjectARX直接訪問AutoCAD的數據庫結構、圖形系統以及AutoCAD幾何構造核心，因此在運行期間能實時拓展CAD功能，也能複用CAD固有的命令來開發新命令。CaD數據庫的核心是BlockTable，BlockTable和所有Block具有一一映射關係。BlockTable此表含有兩個非常重要的記錄：模型空間和圖紙空間，所有的實體(可見對象)均放於塊表AcDbBlockTable中。
其它的設計方案並不具有如此完備的數據-圖元映射關係，所以在圖元生成數據和數據反向生成圖元方面先天不具備優勢。
Autolisp和VBA是初期的二次開發方案，因爲不具備完備的面向對象特性而逐漸淘汰。
基於SDK類庫的C++語言開發並未進入主流方案，其主要原因可能是因爲二者的兼容性問題，雖然C++在面向對象方面較爲強大，但是和ObjecArx在操控各種blocktable方面開發效率不高，所以時至今日也未能進入主流。
其它的繪圖工具，僅僅就是繪圖工具，反向生成圖元不能說不可行而是得不償失地需要進行大量的圖元設計和數據設計工作。
ObjectArx能夠直接訪問CAD的圖形數據庫BLockTable的特性，使得通過ObjectARX類庫二次開發能夠獲得BlockTable與Block的強映射關係，這種強映射關係正好滿足了輔助繪圖工具的需求。
一副CAD圖形就是一個包含有多個表的數據庫，它規定了9個符號表，具體如下：
而網上對ObjectARX的學習資料少之又少，學起來是一個相當困難的挑戰，但是真的就沒有解決方案了嗎？通過大量的調研始終找不到學習資料。
就算費勁苦心參考資料甚至視頻教程，又能堅持在沒人指導、沒人諮詢、沒有案例的情況自己沉浸進去嗎？
於是把眼光投向了培訓機構，經過達內、青鳥、網易課堂、騰訊課堂重重篩選找到了騰訊課堂的雲幽學院。該學院是目前爲止教授較爲完備的CAD深度開發的地方，裏面有一個技術團隊專門做技術指導，有大量的視頻筆記案例供參考學習。
另外一個方案就是設計院的請外包方進行二次開發工作，此時外包的費用問題又是一個需要考慮地方。