|
|
|
|
| LEADER |
04358nmm a2200325 u 4500 |
| 001 |
EB000626093 |
| 003 |
EBX01000000000000000479175 |
| 005 |
00000000000000.0 |
| 007 |
cr||||||||||||||||||||| |
| 008 |
140122 ||| eng |
| 020 |
|
|
|a 9781461554752
|
| 100 |
1 |
|
|a Fodor, George A.
|
| 245 |
0 |
0 |
|a Ontologically Controlled Autonomous Systems: Principles, Operations, and Architecture
|h Elektronische Ressource
|b Principles, Operations, and Architecture
|c by George A. Fodor
|
| 250 |
|
|
|a 1st ed. 1998
|
| 260 |
|
|
|a New York, NY
|b Springer US
|c 1998, 1998
|
| 300 |
|
|
|a XIII, 245 p
|b online resource
|
| 505 |
0 |
|
|a 1.1 Scope -- 1.2 Autonomous Complex Control Systems -- 1.3 Ontological Control -- 1.4 Application Areas For Ontological Control -- References -- Control Concepts And Operations With Pc’s -- 2.1 Programmable Controllers -- 2.2 Modern Programmable Controllers -- 2.3 Causes For A Problematic Control Situation -- References -- Formal Description -- 3.1 Basic Notions And Definitions -- 3.2 Controller States And State Transitions -- 3.3 Control Knowledge Types -- 3.4 Control With An Object PC -- 3.5 The GSO In A Problematic Control Situation -- 3.6 De-synchronizations And The GSO -- 3.7 Summary -- References -- A Well-Determined State Set -- 4.1 Control Configurations -- 4.2 Actions -- 4.3 Well-Defined Controller State With A Configuration -- 4.5 De-Synchronization -- 4.6 A Well-Determined State Set -- 4.7 Goal Paths In A Well-Determined State Set -- 4.8 The Control set and The Collateral Set Of A State -- 4.9 Summary -- References -- Violations of Ontological Assumptions -- 5.1 Ontological Assumptions -- 5.2 The GSOwds -- 5.3 Distinguishing Between De-synchronization causes -- 5.4 Post Synchronization Behavior -- 5.5 Example -- Detecting Voa on a Non Well-Determined State Set -- 6.1 Introduction -- 6.2 Why State Sets Are Not Well Determined? -- 6.3 Effective Control Paths -- 6.4 The State Set Of The GSO-controller -- 6.5 A Well Determined GSO-State Set -- 6.6 De-synchronizations With The GSO-Controller -- 6.7 Conclusions -- The Ontological Controller -- 7.1 Motivations For The Ontological Control Architecture -- 7.2 The State Set Of The Ontological Controller -- 7.3 The Architecture Of The Ontological Controller -- 7.4 Conclusions -- 7.5 Future Research -- References
|
| 653 |
|
|
|a Mechatronics
|
| 653 |
|
|
|a Electrical engineering
|
| 653 |
|
|
|a Control, Robotics, Mechatronics
|
| 653 |
|
|
|a Mechanical Engineering
|
| 653 |
|
|
|a Electrical Engineering
|
| 653 |
|
|
|a Control engineering
|
| 653 |
|
|
|a Robotics
|
| 653 |
|
|
|a Mechanical engineering
|
| 041 |
0 |
7 |
|a eng
|2 ISO 639-2
|
| 989 |
|
|
|b SBA
|a Springer Book Archives -2004
|
| 856 |
4 |
0 |
|u https://doi.org/10.1007/978-1-4615-5475-2?nosfx=y
|x Verlag
|3 Volltext
|
| 082 |
0 |
|
|a 621.3
|
| 520 |
|
|
|a Kevin M. Passino When confronted with a control problem for complicated physical process, a control engineer usually follows a predetermined design procedure. This procedure often begins with the engineer seeking to understand the process and the primary control objectives. A simple example ofa control problem is an automobile "cruise control" that provides the automobile with the capability of regulating its own speed at a driver-specified set-point (e. g. , 55 mph). One solution to the automotive cruise control problem involves adding an electronic controller that can sense the speed of the vehicle via the speedometer and actuate the throttle position so as to regulate the vehicle speed at the driver-specified value. Such speed regulation must be accurate even if there are road grade changes, head-winds, or variations in the number of passengers in the automobile. After gaining an intuitive understanding of the plant's dynamics and establishing the design objectives, the control engineer typically solves the cruise control problem by using an established design procedure. In particular, this control engineering design methodology involves: 1. Modeling/understanding the plant, 2. Construction of a controller to meet specifications (such as stability, rise-time, overshoot, and steady state error), 3. Analysis to make sure that the system will meet the performance objectives (e. g. , we might use mathematical, simulation-based, or experimental analysis), and 4. Iterating on the design until it is possible to "commission" the control system
|