Modelica is the object-oriented modeling language used in SystemModeler to model components and systems. When I first learned Modelica, I read all books available about the language (there are not that many!) and found the book Introduction to Physical Modeling with Modelica by Michael Tiller to be the best out there.

In 2012, when Michael started a Kickstarter campaign to fund the development of a Creative Commons licensed book about Modelica, I was the first person to back it, and Wolfram Research became one of the gold sponsors of the book. A new key feature in SystemModeler 4.0 is the full Modelica by Example book included in the product. This makes it much easier to get started learning Modelica.

I had the opportunity to ask Michael a couple of questions about the new book and Modelica.

Michael Tiller (left) and me, at the North American Modelica Users’ Group Conference at Georgia Tech in 2014.

What is your background in Modelica?

I started using Modelica around 1998, I think. At the time, I was already a very big fan of high-level modeling languages. As an undergraduate, I had used the MAST modeling language (in Saber) extensively. When I started working at Ford, I tried to apply modeling languages to modeling efforts in powertrain modeling.

I quickly ran into two issues. The first was that up until that point, the modeling languages I had looked at were mainly focused around modeling of electrical systems. I needed a modeling language that had a broader vision for modeling that included mechanical and, more importantly, fluid system dynamics. The other issue was having a modeling language that was open. Openness could help avoid vendor lock-in. But more importantly to me, I saw the ability to use a modeling language as a medium for capturing high-level knowledge. That knowledge could be used in a variety of different ways. Compiling the code into something that could be simulated was just part of the story. I wanted a language that was open so that people could plug new ideas and tools into the ecosystem and not have to wait for a single vendor to deliver those capabilities.

Both of these issues led me to Modelica. From there I worked with my colleagues at Ford to inject this technology into the modeling efforts that were underway at Ford. Along the way, I participated in the Modelica design group providing feedback from an industrial user’s perspective. I recognized that one big hindrance to the adoption of Modelica was the lack of a book on the topic. So in 2001, I published the first book on Modelica.

After Ford, I worked in engineering consulting. We used Modelica as one technology, among many, for helping customers to realize the advantages of engineering processes that were more model-based. In 2012, I started my current company, Xogeny, with the goal of helping engineering companies leverage all the amazing software technologies that are out there. That means going beyond just Modelica and FMI and expanding into lots of cloud and web technologies as well. My hope is that eventually engineers who develop models will have all the tools they need to make those models accessible to anyone who wants to use them and to really add value to the engineering process along the way.

Why is Modelica important?

Modelica is important because, as I mentioned previously, it captures a representation of people’s models in an open way and in a way that can be reasoned about. This comes from the fact that Modelica is a declarative language, not an imperative language. When you deal with typical programming languages, the imperative constructs (e.g., do this, now do that, now loop until this is true, then overwrite that result) make it nearly impossible to actually extract the high-level intention of the user (at least not without a tremendous amount of discipline). Modelica is not a language of statements and operations, it is a language of relationship: how variables relate to each other through an equation, how the values of a variable are related to a type (and its physical units), how a resistor is related to a capacitor through connections in a schematic diagram. The point is that the structure of the model and all of these relationships are always preserved in Modelica.

This property has been leveraged extensively to create very fast simulations by being able to reason about these relationships. We can see which variables depend on which other variables and use this to efficiently perform calculations, minimize the number of variables involved in solving nonlinear systems, recognize which signals are synchronized with other signals to ensure determinism in results, and so on.

That being said, I think there are other aspects of the engineering process that can benefit from this approach. So I don’t think we’ve fully leveraged the knowledge captured in Modelica models yet.

Why is learning Modelica important?

There are lots of approaches to simulation that kind of mirror computer programming where you start with some known values, then you compute something from those, then you compute something from those. Unfortunately, those kinds of approaches have limitations. But those limitations are very hard to see when you are just starting out. It is very common (both in engineering and in programming) for people to pick technologies that are easy to get started with, but don’t scale very well once you get into larger, more complex problem domains. But you can’t really blame people for taking the path of least resistance when trying to learn technologies. My goal, in writing both of my books, was to provide an easy path for people to learn about Modelica because, in my opinion, Modelica “has legs.” It can get you through those large and complex problems. But you have to learn it first before you can apply it to those kinds of problems.

This is an interesting and challenging question. The real advantages of Modelica are hard to explain to people at first, and often by the time they get to the point where they recognize the limitations of other technologies, they are so far down that road and so invested in them, they don’t have the option to switch technologies. That’s a big driver for me in trying to get people on the Modelica track from the start.

I think there is a bigger picture here, which is the value of standards in general. Many engineering companies want to focus on their core competency and want to “outsource” lots of stuff to vendors. But I feel like companies are more and more appreciating not just the cost in terms of dollars of this approach, but also the cost in terms of agility. They can’t change anything easily because of all the tear-up involved due to of vendor lock-in or just poor planning. The engineering community needs to start putting more focus on software and IT standards (and not just standards for fasteners, materials, etc).

What is the purpose of the book?

As I say in the dedication of the book, “I’m not interested in capitalizing on my knowledge of Modelica, I want to share it with others so they can experience the same joy I do in exploring this subject.” It is as simple as that. The nature of the Kickstarter project might give the appearance that this is some kind of business undertaking. But if that were the case, I wouldn’t be giving the book away on the web for free. The money was just to give me the freedom to really invest time in the project (and allow me to continue to invest time in it as it develops).

Excerpt from the Modelica by Example book inside SystemModeler.

Any final thoughts?

I hope the book excites people (students in particular) about modeling and simulation. I think Modelica is a great example of a technology that is open, scalable, and industrially proven. It isn’t the only one. For me, that is the most exciting part. There are so many amazing technologies out there that we can apply to engineering, and every day I jump out of bed excited to see how to do just that.

I think in broader terms, my hope is to demonstrate to people in the engineering world the power of open collaboration. Whether that is open source, creative commons, standardization, whatever. Engineering is too “closed.” Paranoia about intellectual property related issues is very strong, and it makes people afraid to collaborate and discuss. I think people are also hesitant to leverage more advanced software and IT technologies. I think that is partly because they haven’t been given enough training to appreciate the value of these technologies and feel competent to participate. But I also think engineering is too segregated from software and IT. For example, when I look at lots of companies, the IT operations are very strongly focused on making sure email works and the networks are functioning and viruses aren’t spreading. All that is important, but what I don’t see a lot of is IT organizations having responsibilities to support the engineering process. Most engineers I talk to feel like every time they go to IT departments, they are told “No” to anything they want to do. The engineers are subservient to the IT departments. I think that is crazy. After all, these are engineering companies. Engineering should be their top priority. So I think that mindset has to change, and the book, my blog, and various other things I’m doing are just trying to make the value for open collaboration and standards (among other things) so valuable that we can hopefully break down some of those barriers.