什麼是控制系統、機器人系統架構師乃至總工程師所需的大局觀？

01-03

發點感慨隨便寫寫吧，畢竟自己不夠格，大家不要當真，純為自己打發時間。

這個有大菊觀的位置，有點像，或者去類比IT界的兩種人，就是軟體架構師或者全棧工程師。軟體工程在社會實際需求的驅動下發展了這麼多年，對於如何抽象、組織和管理大型軟體工程已經形成了理論體系，包括軟體開發的流程模型、各種設計模式、描述大型軟體結構的建模語言（UML）等。所以理論上來說，是可以有專門學習軟體架構的人，直接成為專職軟體架構師的，這種人，在業界就會被稱為：「PPT架構師」，他們解決問題的方案，就被稱為「冰箱如何關大象」。因為沒有紮實的底層經歷，不明白實現的具體工具的優缺點，設計的解決方案不是想當然漏洞百出，就是一紙空話什麼都沒說。所以一個好的架構師，必然是即有著良好的宏觀設計的感覺，又有著紮實的底層技術，面對著需求能夠良好的折衷功能的實現和開發的代價，還有著良好的溝通能力，可以帶領團隊走向勝利的。

近年來又有著一個很火的稱謂，叫做全棧程序員。我早就已經遠離計算機第一線了，我的感覺是為了敏捷開發而生的概念，即存在一個全能型的碼農，可以一條龍的搞定所有的技術。這樣子可以有效地降低開發成本，因為根據軟體工程的理論，開發人員的增長和開發效率的增長是相反的。一個人搞定一切，就減少了很多設計、溝通和交流的成本。然而這更像是一個概念，技術再全面的人，面對著新的需求也有著覆蓋不了的東西。

在此基礎上類比控制工程中的架構師。首先是控制工程中還沒形成高層的設計體系，不存在那種專註於學習如何在頂層設計控制系統的人。這是因為控制工程覆蓋的面實在是太廣，不同行業中的控制問題千差萬別，不是軟體行業中起碼常用的編程語言兩隻手還是勉強數的過來的。

事實上就算都是搞控制的，在不同的行業之中想法也非常不一樣。我博士論文開題的時候，委員會裡四個教授，A是搞振動控制和動力學的，B是搞電路電子的，C是搞車輛導航的，D才是個傳統意義上專搞控制系統與工程的，均有業界知名度。我有一頁ppt上有個頻域響應圖，但是橫縱坐標都不是用的dB和decade，搞車輛的大牛C當場表示我的圖不對，單位不對，而A和B同時表示他們喜歡這種原始的不縮放的坐標軸，而D淡定的表示無所謂。。。

而在業界中對於不同的具體行業，需求的專業技能和語言是很大不同的。比如說搞化工過程式控制制的，會把感測器叫變送器，接觸的各種儀器儀錶信號都是標準幅度的，熟悉各種閥門，變頻器，中控軟體要用組態王之類，控制器也都是使用標準信號介面的封好了的標準儀器；再看專搞感測器的，感測器內部也是有控制系統的，會花大量的時間和精力去研究感測器內部的機理，設計盡量線性的驅動器和反饋信號，而對控制器設計本身相對粗淺，但是別不服，人家就是能做出好用的東西來。( @小心假設你這坑挖的真大！我碼字碼了半天了，又多又不好理思路啊！)。

所以我覺得控制架構師，一定是依託於一個具體行業的，並且從底層做起來的，技能樹應該包括：

1.良好的控制理論。這個應該是必須的吧，最起碼是能通曉基礎理論，並且有著跟學界溝通的能力，能辨別有價值的新理論。

2.良好溝通能力。要帶領團隊走向勝利的，溝通能力無需多言吧。

3.優秀的本行業內的技術能力。這個有點像全棧工程師的意思了，搞工控的儀器儀錶選型，組態軟體設計，布線；搞機器人的電機，機械設計，單片機或dsp；搞功率器件的電力電子設計分析之類的。不能說是全才吧，那畢竟不現實，最起碼是得有兩三樣拿得出手的優秀的技能，並且對於新的需求有著迅速點開新技能樹的能力，否則那就是全棧二把刀而不是全棧工程師了。

4.設計理念。這個真有點是難以言傳的意思了，就像是另一個答案說的「胸中有丘壑」的樣子，但是設計理念也是靠自己的實踐配合著自己的做事風格不斷地建立起來的，並非是開腦洞的。我個人的感覺是，在工程中設計應該要折衷，要在達成目標的時候盡量選用簡單可靠合適的方案，不要自己給自己設置障礙。能用線性器件的盡量用線性度好的，真得用非線性度高的器件的時候，也要能有迎難而上解決問題的能力。要是不能解決新問題，那就又成了「PPT控制工程師」了。

本回答純屬YY，請慎讀

創業一小段時間，一年吧，苦逼的不行。這輩子最想做的工作就是類似於機器人系統架構師這種高大上的工作。請告訴我真的有這種職位么，是不是自己YY的。。。

反正匿名，那我就是傳說中的系統架構師！

本人現在的情況是，所有方面的水平，包括機械，電路設計，計算機從底層到操作系統，然後是各類導航控制理論都懂一點兒，但是是半吊子，或者可能連半吊子都不到。最大的作用是考慮手裡有多少錢，能買什麼，該買什麼，各種加工有多少錢，設計整體系統盡量保證以最少的錢把系統能跑起來，然後後面哪裡缺人搭把手，流程監督神馬的別提了，就是定了計劃埋頭干，就那麼幾個人。。。隔一周總結就好。幸虧隊友給力，還勉強能跟上節奏，也有坑的時候，那就只能補坑了。在定計劃的時候不以裝逼為目的，盡量考慮個人情況，以不坑隊友，不坑自己為目標。。。

我夢想中的系統架構師本應該像神一樣，眼中有山水，胸中有丘壑。大手一揮，系統的所有細節就可以在腦子中全部過一遍。設計什麼樣子完成就是什麼樣子，設計工期多少完成時間也能剛好。

然而，我感覺現在自己就像狗一樣東奔西跑，各處都是沒遇到過的問題，各處都要調整。T_T

T_T真的該用功讀書的T_T

如下選自：

Feedback Control Theory

John C. Doyle, Bruce A. Francis, Allen R. Tannenbaum

https://www.amazon.com/Feedback-Control-Theory-Electrical-Engineering/dp/0486469336/ref=sr_1_1?ie=UTF8qid=1476188483sr=8-1keywords=john+doyle+control

The process of designing a control system generally involves many steps. A typical scenario is as follows:
1. Study the system to be controlled and decide what types of sensors and actuators will be used and where they will be placed.
2. Model the resulting system to be controlled.
3. Simplify the model if necessary so that it is tractable.
4. Analyze the resulting model; determine its properties.
5. Decide on performance specifications.
6. Decide on the type of controller to be used.
7. Design a controller to meet the specs, if possible; if not, modify the specs or generalize the type of controller sought.
8. Simulate the resulting controlled system, either on a computer or in a pilot plant.

9. Repeat from step 1 if necessary.
10. Choose hardware and software and implement the controller.
11. Tune the controller on-line if necessary.

以及接下來的兩段：

It must be kept in mind that a control engineer』s role is not merely one of designing control
systems for fixed plants, of simply 「wrapping a little feedback」 around an already fixed physical
system. It also involves assisting in the choice and configuration of hardware by taking a system-wide
view of performance. For this reason it is important that a theory of feedback not only lead
to good designs when these are possible, but also indicate directly and unambiguously when the
performance objectives cannot be met.
It is also important to realize at the outset that practical problems have uncertain, non-minimum-phase
plants (non-minimum-phase means the existence of right half-plane zeros, so the
inverse is unstable); that there are inevitably unmodeled dynamics that produce substantial uncertainty,
usually at high frequency; and that sensor noise and input signal level constraints limit
the achievable benefits of feedback. A theory that excludes some of these practical issues can
still be useful in limited application domains. For example, many process control problems are so
dominated by plant uncertainty and right half-plane zeros that sensor noise and input signal level
constraints can be neglected. Some spacecraft problems, on the other hand, are so dominated by
tradeoffs between sensor noise, disturbance rejection, and input signal level (e.g., fuel consumption)
that plant uncertainty and non-minimum-phase effects are negligible. Nevertheless, any general
theory should be able to treat all these issues explicitly and give quantitative and qualitative results
about their impact on system performance.

其他回答里，說控制系統沒有架構師，或者只需要每個都懂一點，然後就可以了，我完全無法認同。

控制系統的架構師需要對每個細節都非常了解，知其然且知其所以然。

所謂的控制系統，本身是一個非常複雜的概念。因為講到控制系統可能有很多個維度：控制飛機發動機的控制系統、控制一架飛機的控制系統、控制一個機場的控制系統、控制航空網路的控制系統。

國家電網控制網路，是否和中石油傳輸石油和天然氣的控制網路一樣呢？核電站里的控制系統和印刷廠里生產線的控制系統是否一樣呢？輪船碼頭裡的控制系統和製藥廠里的控制系統是否大同小異呢？倉儲的控制系統和化工廠的控制系統是否可以用同樣的產品呢？

答案是每個都不一樣，基本很難復用，而且區別很大。為什麼不一樣，有什麼區別？每個被控制對象的物理性質、空間尺寸、時間快慢都不一樣。控制系統根據工藝要求、安全性要求、可靠性要求的不同又衍生出不同的設計策略。

在學校里，學自動化的同學可能只能了解到演算法設計，而對實際工藝知之甚少。因此也很難理解為什麼PLC就有小型、中型、大型之分，然後還有DCS、SCADA。每個都是有區別的。

然後細分到每個場景，飛機、石油石化、電廠、港口碼頭、鐵路交通，每個地方的需求都是不同的。甚至外國巨頭們也是各有長處，西門子、霍尼韋爾兩家基本上就很少直接競爭。西門子做核電站、火電站、做鐵路交通；霍尼韋爾做飛機、做石油石化、做港口碼頭。

那麼什麼樣的人會是這樣的控制系統架構師呢？在這些自控廠家的研發部門，都有精通控制系統的大牛，例如在和利時、在浙大中控等等。都有專門的產品經理分析主流的PLC、DCS、SCADA的各項功能。其基本產品要覆蓋80%的各類基本產品需求。然後高可靠性應用、高實時性應用還有高利潤的應用場景，都是訂製開發的系統。

以上這些需要很多年很多年的經驗積累，而不是一天兩天的時間就能培養的素質。

大概看了一下前面的答案，大家好像還是比較關注在技術的層面，例如如何協調各個模塊的耦合，一個功能應該用軟體還是硬體實現，如何成本和性能之間取得平衡。。。

不過在我看來，做為架構師或者是總工。站的角度應該高於技術，要從整個產品的角度來考慮。開始搭建架構的時候，先得想想什麼是客戶的真正需求，法規有什麼限制，產線能力如何。這樣開發團隊可以避免很多無謂的消耗。

成本，包括用戶的使用成本！

技術已經儲備了幾十年了，可以算傳統行業！

我們將機器人系統分為七個層次.

技術層,

零件層

組件層

產品層

應用層

方案層

行業層.

可參考機器人總體思考