Information on Model Driven Development of Data Acquisition and Control Systems. ---- '''Questions''': * What is the state of the art for Model Driven Development of Data Acquisition and Control Systems? * Who are the leading experts? * Success stories? * References? * Leading tools? * Has it been applied to designing scientific-instrument systems? -- KelleyHarris ---- '''Success Stories''': ---- '''Leading Experts''': ---- '''References''': ---- '''Tools''': ---- '''Other Related Resources''': * I-Logix, http://www.ilogix.com/, "model-driven development (MDD) solutions for embedded systems design through software development focused on real-time UML 2.0 embedded applications." * IMEC (Interuniversity MicroElectronics Center) "Europe's leading independent research center in the field of microelectronics, nanotechnology, enabling design methods and technologies for ICT systems." http://www.imec.be/ * BEACON FOR Simulink, ADI (Applied Dyamics International), http://www.adi.com/products_be_bss.htm, "BEACON FOR Simulink,is a set of softwareengineering tools for generating complex software andunit test vectors for use in embedded control systems." * NI MATRIXx Design and Development Tools, http://ni.com/matrixx/design_development, "For more than 20 years, engineers worldwide have relied on the MATRIXx product family for control design applications in automotive, aerospace and defense, process control, and academic environments. ... automatic embedded code generation for C and Ada" * tinsilica ---- '''Uses in scientific instruments''': ---- Could it be applied to designing atomic-force microscope systems? -- KelleyHarris Here is a generous offer by WardCunningham: "Here is an idea ... Take all your knowledge of afm control and separate from that knowledge the basic operations that are present in all afm applications. Make sure this includes every time critical algorithm that has to be written in careful c++. This is the start on your model. Now fork your codebase so that you can refactor aggressively. Get a copy of python and lean how it likes to work. Write some unit tests in python that make calls on your model in a pythonish way. Refactor your forked c++ modules until the python tests pass. Repeat this testing and refactoring until writing typical afm applications is embarrassingly easy. Announce that this is model driven development. Some tips.... Keep the ui for this stuff very simple. Make sure that you can use python's immediate mode to write non-trivial applications in a few lines. Let this drop results somewhere and use a few cgi scripts to browse current and past results. Call this a results database browser and feature its simplicity. Write some demos of the afm's most valuable features. Ask the guys in marketing what people on an exhibit floor would understand and love in just a minute. Write demos that do this and let them use them. Show them how to hack python. Figure out how to exploit python's keyword arguments to make little demo scripts look beautiful. Call this a domain specific language. Emphasize how python's abstraction capabilities are both more straightforward and more powerful than graphical input. Just in case, write an alternate library that will run your demos but capture calls in a data structure instead of running them. Use some graph drawing software like Dot to draw pictures of these structures. Show these to the marketing guys and ask how they would use them to sell afms. I'll leave you to post these ideas on wiki if you think there is any merit to them. Mostly I'm trying to suggest things that are both relatively easy (assuming one has real domain knowledge) and offer open-ended power. The marketing connection is just to give you practice wielding that power once you have it. Otherwise you might not appreciate what you've done. Send me some pictures that you make this way. If this saves the company and you end up rich and famous, send me an afm. Best regards." -- WardCunningham 9/19/04 ---- ---- Keywords: Model-driven architecture, closed-loop feedback control systems, scientific instrumentation, concurrent engineering, software reuse, domain engineering ---- See also ModelDrivenSoftwareDevelopment, ModelDrivenDevelopment, ModelDrivenArchitecture,