Difference between revisions of "Introduction to Simantics Architecture"
Jump to navigation
Jump to search
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Background and motivation == | == Background and motivation == | ||
| − | The synthesis of the Simantics architecture has its foundation on a series of | + | The synthesis of the Simantics architecture has its foundation on a series of research projects at [http://www.vtt.fi/?lang=en VTT Technical Research Centre of Finland] on software architectures and data models [http://lib.tkk.fi/Diss/2002/isbn9513860124/] and 20 years of experience from implementation of an industrial process simulator [http://apros.vtt.fi]. The resulting synthesis was put into motion in 2005 when a decision was made to start a development of an ontology-based approach for modelling and simulation. The synthesis is a balance between concepts of theoretical computer science and mathematical logic and concrete user needs in industrial simulation and modelling. The position of VTT between the academia and the industry has given the development team a broad view of the state of the art in modelling and simulation. |
== On objectives and the architecture == | == On objectives and the architecture == | ||
| − | The architecture of a software system can very naturally be judged by the way it fulfills the most important objectives of the system. The objective of Simantics can in one phrase can be described as | + | The architecture of a software system can very naturally be judged by the way it fulfills the most important objectives of the system. The objective of Simantics can in one phrase can be described as: |
| − | * Simantics shall increase the productivity of modelling and simulation | + | * Simantics shall increase the productivity of modelling and simulation. |
| − | Productivity should be measured on many levels from Kernel Developer to Model User. It should cover the development of Simantics itself and integration of new tools into Simantics as well as end user tasks. | + | Productivity should be measured on many levels from a Kernel Developer to a Model User. It should cover the development of Simantics itself and the integration of new tools into Simantics as well as end user tasks. The key means in increasing productivity are: |
| − | * Availability | + | * '''Availability''': In many cases, the data and tools needed to perform an engineering task do exist but are not practically available to the user. The architecture should make this data and tools available. |
| − | * Accessibility | + | * '''Accessibility''': The user should be able to accomplish as much as possible with as little effort as possible. Engineers rely on tools to do their work. The architecture must endorse the emergence of powerful and easy to use tools. |
| − | * Automation | + | * '''Automation''': Suitable automation can in many cases create order of magnitude increases in productivity. The architecture should lower the effort for creating automation. |
| − | * Accumulation | + | * '''Accumulation''': People reach higher by accumulating knowledge and building on past results. The architecture should endorse practices which accumulate work into reusable results. |
| − | * Quality | + | * '''Quality''': In current state of the art error prevention and error recovery incur large costs in engineering. Better confidence in achieved quality also leads to more efficient solutions. The architecture should provide support for raising the quality of engineering work. |
| − | * Teamwork | + | * '''Teamwork''': Modelling and simulation is increasingly networked and global. Efficient teams are needed for increasing productivity. The architecture should take teamwork as a given fact and support it in all its structures. |
Being a platform for modelling and simulation, the requirements for real-time operations are also a key factor in determining the architecture. | Being a platform for modelling and simulation, the requirements for real-time operations are also a key factor in determining the architecture. | ||
| Line 24: | Line 24: | ||
=== Availability === | === Availability === | ||
| − | * Make integration of existing data and tools into Simantics as easy as possible. Make sure that existing models can be represented using generic semantic representations. Bring existing data models into Simantics as is. Provide toolkits for implementing communications with the tools. | + | * Make the integration of existing data and tools into Simantics as easy as possible. Make sure that existing models can be represented using generic semantic representations. Bring existing data models into Simantics as is. Provide toolkits for implementing communications with the tools. |
* Create powerful generic tools for integrating data and tools inside Simantics. | * Create powerful generic tools for integrating data and tools inside Simantics. | ||
* Keep solutions to different problems as clean and as separate as possible. Integrate these solutions. | * Keep solutions to different problems as clean and as separate as possible. Integrate these solutions. | ||
| − | * Make most useful all-purpose tools freely available parts of the platform. | + | * Make the most useful, all-purpose tools freely available parts of the platform. |
=== Accessibility === | === Accessibility === | ||
| − | * Keep down complexity. Use few powerful abstractions to accomplish many tasks. | + | * Keep down the complexity. Use few powerful abstractions to accomplish many tasks. |
| − | * Concentrate | + | * Concentrate efforts on a few powerful and generic tools to make them highly productive. |
* Use layered approaches to expose powerful tools step by step. | * Use layered approaches to expose powerful tools step by step. | ||
| Line 43: | Line 43: | ||
=== Accumulation === | === Accumulation === | ||
| − | * Develop standard models and toolkits which support abstraction, decomposition and reuse | + | * Develop standard models and toolkits which support abstraction, decomposition and reuse. |
| − | * Focus on long term shared data management inside organisations | + | * Focus on long term shared data management inside organisations. |
=== Quality === | === Quality === | ||
| − | * Increase the semantic content of data | + | * Increase the semantic content of data. |
| − | * Increase automation both in model creation and in quality assurance | + | * Increase automation both in model creation and in quality assurance. |
| + | * Understand the end user process you are developing a feature for. Design and implement logical, easy-to-follow functionalities. | ||
=== Teamwork === | === Teamwork === | ||
| Line 66: | Line 67: | ||
=== Data driven architecture === | === Data driven architecture === | ||
| − | Simantics is a set of services built on top of a semantic data model. The main focus points of the architecture are | + | Simantics is a set of services built on top of a semantic data model. The main focus points of the architecture are: |
* Emphasis on agility and expressivity. Arbitrary different models can co-exist in the same database. | * Emphasis on agility and expressivity. Arbitrary different models can co-exist in the same database. | ||
| Line 80: | Line 81: | ||
=== Plugin architecture === | === Plugin architecture === | ||
| − | Simantics products are built up from a set of plugins. The main implications of a plugin architecture are | + | Simantics products are built up from a set of plugins. The main implications of a plugin architecture are: |
| − | * Plugins are software components with well-defined interfaces and dependencies | + | * Plugins are software components with well-defined interfaces and dependencies. |
| − | * Plugin-based software products can be configured by adding and removing plugins | + | * Plugin-based software products can be configured by adding and removing plugins. |
=== Integration architecture === | === Integration architecture === | ||
| − | A central goal of Simantics is to be able to bring existing tools and models into the Simantics framework for integration with other tools and models already in Simantics. Simantics does this by | + | A central goal of Simantics is to be able to bring existing tools and models into the Simantics framework for integration with other tools and models already in Simantics. Simantics does this by: |
* Implementing the native data model of the integration target in Simantics. The emphasis is on easy synchronisation and is supported by automatic tools and frameworks (solver toolkit). | * Implementing the native data model of the integration target in Simantics. The emphasis is on easy synchronisation and is supported by automatic tools and frameworks (solver toolkit). | ||
| Line 94: | Line 95: | ||
=== Layered architecture === | === Layered architecture === | ||
| − | Simantics aims to increase modelling productivity by adopting best practices in modelling such as hierarchical decomposition and component-based reuse. Simantics does this by | + | Simantics aims to increase modelling productivity by adopting best practices in modelling such as hierarchical decomposition and component-based reuse. Simantics does this by: |
* Providing a few well-thought templates (e.g. structural, DEVS co-simulation) with support for modelling cases in typical engineering systems. | * Providing a few well-thought templates (e.g. structural, DEVS co-simulation) with support for modelling cases in typical engineering systems. | ||
| Line 100: | Line 101: | ||
* Providing implementation frameworks for common tasks such as solver distribution. | * Providing implementation frameworks for common tasks such as solver distribution. | ||
| − | A focal use case of Simantics is user interface development. Simantics aims to make this quick and easy by | + | A focal use case of Simantics is user interface development. Simantics aims to make this quick and easy by: |
* Including a common set of typical user interface tools. These include 2D diagramming, Model browsing, Property sheets, Charts, Spreadsheet and Documentation editing. | * Including a common set of typical user interface tools. These include 2D diagramming, Model browsing, Property sheets, Charts, Spreadsheet and Documentation editing. | ||
| − | * Using a semantic data driven configuration of the tools | + | * Using a semantic data driven configuration of the tools. |
| − | * Making the tools extensible via plugins | + | * Making the tools extensible via plugins. |
* Providing frameworks for easy interaction between the tools including clipboard, DnD, workspace selection and requests. | * Providing frameworks for easy interaction between the tools including clipboard, DnD, workspace selection and requests. | ||
=== Team architecture === | === Team architecture === | ||
| − | The emphasis on teamwork in Simantics is implemented using the following means | + | The emphasis on teamwork in Simantics is implemented using the following means: |
| − | * A shared semantic database with history and access management. The approach follows the example of highly successful and popular systems such as CVS and SVN | + | * A shared semantic database with history and access management. The approach follows the example of highly successful and popular systems such as CVS and SVN. |
| − | * Integrated documentation tools with fast manual content creation and support for transferring user interface data (e.g. diagrams, tables, requests) into documents | + | * Integrated documentation tools with fast manual content creation and support for transferring user interface data (e.g. diagrams, tables, requests) into documents. |
| − | * Emphasis on diagramming and diagram self-documentation for making models accessible | + | * Emphasis on diagramming and diagram self-documentation for making models accessible. |
== Structure of the technical specification == | == Structure of the technical specification == | ||
Latest revision as of 10:02, 10 February 2011
Contents
Background and motivation
The synthesis of the Simantics architecture has its foundation on a series of research projects at VTT Technical Research Centre of Finland on software architectures and data models [1] and 20 years of experience from implementation of an industrial process simulator [2]. The resulting synthesis was put into motion in 2005 when a decision was made to start a development of an ontology-based approach for modelling and simulation. The synthesis is a balance between concepts of theoretical computer science and mathematical logic and concrete user needs in industrial simulation and modelling. The position of VTT between the academia and the industry has given the development team a broad view of the state of the art in modelling and simulation.
On objectives and the architecture
The architecture of a software system can very naturally be judged by the way it fulfills the most important objectives of the system. The objective of Simantics can in one phrase can be described as:
- Simantics shall increase the productivity of modelling and simulation.
Productivity should be measured on many levels from a Kernel Developer to a Model User. It should cover the development of Simantics itself and the integration of new tools into Simantics as well as end user tasks. The key means in increasing productivity are:
- Availability: In many cases, the data and tools needed to perform an engineering task do exist but are not practically available to the user. The architecture should make this data and tools available.
- Accessibility: The user should be able to accomplish as much as possible with as little effort as possible. Engineers rely on tools to do their work. The architecture must endorse the emergence of powerful and easy to use tools.
- Automation: Suitable automation can in many cases create order of magnitude increases in productivity. The architecture should lower the effort for creating automation.
- Accumulation: People reach higher by accumulating knowledge and building on past results. The architecture should endorse practices which accumulate work into reusable results.
- Quality: In current state of the art error prevention and error recovery incur large costs in engineering. Better confidence in achieved quality also leads to more efficient solutions. The architecture should provide support for raising the quality of engineering work.
- Teamwork: Modelling and simulation is increasingly networked and global. Efficient teams are needed for increasing productivity. The architecture should take teamwork as a given fact and support it in all its structures.
Being a platform for modelling and simulation, the requirements for real-time operations are also a key factor in determining the architecture.
Architectural reasoning
Availability
- Make the integration of existing data and tools into Simantics as easy as possible. Make sure that existing models can be represented using generic semantic representations. Bring existing data models into Simantics as is. Provide toolkits for implementing communications with the tools.
- Create powerful generic tools for integrating data and tools inside Simantics.
- Keep solutions to different problems as clean and as separate as possible. Integrate these solutions.
- Make the most useful, all-purpose tools freely available parts of the platform.
Accessibility
- Keep down the complexity. Use few powerful abstractions to accomplish many tasks.
- Concentrate efforts on a few powerful and generic tools to make them highly productive.
- Use layered approaches to expose powerful tools step by step.
Automation
- Make the system extensible both in representation and in program logic.
- Make parts of the system highly configurable and open.
- Design interfaces to allow external modification.
Accumulation
- Develop standard models and toolkits which support abstraction, decomposition and reuse.
- Focus on long term shared data management inside organisations.
Quality
- Increase the semantic content of data.
- Increase automation both in model creation and in quality assurance.
- Understand the end user process you are developing a feature for. Design and implement logical, easy-to-follow functionalities.
Teamwork
- Process all data using a shared repository model with basic multiple user functionality such as transactions, version control and access control.
Real-time
- Make a low-compromise real-time data access subsystem for transferring runtime data.
- Prepare for different profiles of data volatility.
Architectural structures
Data driven architecture
Simantics is a set of services built on top of a semantic data model. The main focus points of the architecture are:
- Emphasis on agility and expressivity. Arbitrary different models can co-exist in the same database.
- Emphasis on large scale industrial applications. Large data sets of semantic and primitive data need to be processes.
- Emphasis on real-time applications. Fast modification and tracking of changes.
- Emphasis on teamwork.
- Emphasis on data model integration with client Java code. Client is supported in the implementation of the data semantics.
Simantics aims to enable a data-driven approach in all phases of the model-assisted decision support process.
The data model is detailed in Data View
Plugin architecture
Simantics products are built up from a set of plugins. The main implications of a plugin architecture are:
- Plugins are software components with well-defined interfaces and dependencies.
- Plugin-based software products can be configured by adding and removing plugins.
Integration architecture
A central goal of Simantics is to be able to bring existing tools and models into the Simantics framework for integration with other tools and models already in Simantics. Simantics does this by:
- Implementing the native data model of the integration target in Simantics. The emphasis is on easy synchronisation and is supported by automatic tools and frameworks (solver toolkit).
- Integrating the native data model with other models using semantic mappings.
Layered architecture
Simantics aims to increase modelling productivity by adopting best practices in modelling such as hierarchical decomposition and component-based reuse. Simantics does this by:
- Providing a few well-thought templates (e.g. structural, DEVS co-simulation) with support for modelling cases in typical engineering systems.
- Providing support to translate these templates into native tool formats increasing the expressivity of the tools native capability.
- Providing implementation frameworks for common tasks such as solver distribution.
A focal use case of Simantics is user interface development. Simantics aims to make this quick and easy by:
- Including a common set of typical user interface tools. These include 2D diagramming, Model browsing, Property sheets, Charts, Spreadsheet and Documentation editing.
- Using a semantic data driven configuration of the tools.
- Making the tools extensible via plugins.
- Providing frameworks for easy interaction between the tools including clipboard, DnD, workspace selection and requests.
Team architecture
The emphasis on teamwork in Simantics is implemented using the following means:
- A shared semantic database with history and access management. The approach follows the example of highly successful and popular systems such as CVS and SVN.
- Integrated documentation tools with fast manual content creation and support for transferring user interface data (e.g. diagrams, tables, requests) into documents.
- Emphasis on diagramming and diagram self-documentation for making models accessible.
Structure of the technical specification
More details of the technical specification can be found in the following sections
