Overview
The commercial success of Proteus VSM will depend considerably on the availability of large numbers of models. With this in mind, we see it as crucial to develop a market for models that will operate between users of the software. Put another way, if you need to develop a model in order to use the software for your own application, the cost and effort involved may present a barrier. However, if you can also sell that model to other users, the barrier may be overcome. The Internet provides an ideal mechanism for establishing such a marketplace.
To make this business model work, it is necessary to ensure that models can only be used when they have been paid for, and this is the role of the Licencing API within Proteus VSM. Essentially, each user of the system is allocated a Customer ID, which is unique to their copy and a Customer Key which ties that copy to their name and company details. Potentially we can also tie it to their hardware or OS installation.
Each model that is created is allocated a Product ID which is again unique. Then, to use that model on a given installation, the customer is issued with a Product Key. This key is a signature of the Customer ID and the Product ID, and validates that the model can be used with that particular installation of the software.
Obtaining Product IDs for your Models
Before you can begin developing new models, you will need to obtain an allocation of unique product IDs from us. You can do this by emailing us at [email protected]. We will supply you with a base value from which to allocate Product IDs, and a product key file that enables these IDs for your copy of Proteus VSM.
How a Model is Authorized
In order to receive service from the simulator, a model must issue a valid authorization request as soon as it is constructed. It does this using theILICENCESERVER::authorizefunction which takes a Product ID as its single argument. The Licence Server examines the set of installed Product Keys and will authorize the model only if an appropriate key is present. If the model fails to authorize, the ILICENCESERVER::authorizefunction returns FALSE, and the model object will not receive any further calls from the simulator.
Typically, the model constructor code will read as follows:
extern "C"
{ ISPICEMODEL * _export createspicemodel (CHAR *dvc, ILICENCESERVER *ils) { ISPICEMODEL *newmodel = new MYMODEL (dvc);
ils->authorize(MY_PRODUCT_ID);
return newmodel;
} }
In some cases it is more appropriate to pass the ILICENCESERVER object to the model class constructor itself, especially if the model supports bothbatch modeandinteractivesimulations.
Overview
The commercial success of Proteus VSM will depend considerably on the availability of large numbers of models. With this in mind, we see it as crucial to develop a market for models that will operate between users of the software. Put another way, if you need to develop a model in order to use the software for your own application, the cost and effort involved may present a barrier. However, if you can also sell that model to other users, the barrier may be overcome. The Internet provides an ideal mechanism for establishing such a marketplace.
To make this business model work, it is necessary to ensure that models can only be used when they have been paid for, and this is the role of the Licencing API within Proteus VSM. Essentially, each user of the system is allocated a Customer ID, which is unique to their copy and a Customer Key which ties that copy to their name and company details. Potentially we can also tie it to their hardware or OS installation.
Each model that is created is allocated a Product ID which is again unique. Then, to use that model on a given installation, the customer is issued with a Product Key. This key is a signature of the Customer ID and the Product ID, and validates that the model can be used with that particular installation of the software.
Obtaining Product IDs for your Models
Before you can begin developing new models, you will need to obtain an allocation of unique product IDs from us. You can do this by emailing us at [email protected]. We will supply you with a base value from which to allocate Product IDs, and a product key file that enables these IDs for your copy of Proteus VSM.
How a Model is Authorized
In order to receive service from the simulator, a model must issue a valid authorization request as soon as it is constructed. It does this using theILICENCESERVER::authorizefunction which takes a Product ID as its single argument. The Licence Server examines the set of installed Product Keys and will authorize the model only if an appropriate key is present. If the model fails to authorize, the ILICENCESERVER::authorizefunction returns FALSE, and the model object will not receive any further calls from the simulator.
Typically, the model constructor code will read as follows:
extern "C"
{ ISPICEMODEL * _export createspicemodel (CHAR *dvc, ILICENCESERVER *ils) { ISPICEMODEL *newmodel = new MYMODEL (dvc);
ils->authorize(MY_PRODUCT_ID);
return newmodel;
} }
In some cases it is more appropriate to pass the ILICENCESERVER object to the model class constructor itself, especially if the model supports bothbatch modeandinteractivesimulations.
LICENCING INTERFACE
Overview
The commercial success of Proteus VSM will depend considerably on the availability of large numbers of models. With this in mind, we see it as crucial to develop a market for models that will operate between users of the software. Put another way, if you need to develop a model in order to use the software for your own application, the cost and effort involved may present a barrier. However, if you can also sell that model to other users, the barrier may be overcome. The Internet provides an ideal mechanism for establishing such a marketplace.
To make this business model work, it is necessary to ensure that models can only be used when they have been paid for, and this is the role of the Licencing API within Proteus VSM. Essentially, each user of the system is allocated a Customer ID, which is unique to their copy and a Customer Key which ties that copy to their name and company details. Potentially we can also tie it to their hardware or OS installation.
Each model that is created is allocated a Product ID which is again unique. Then, to use that model on a given installation, the customer is issued with a Product Key. This key is a signature of the Customer ID and the Product ID, and validates that the model can be used with that particular installation of the software.
Obtaining Product IDs for your Models
Before you can begin developing new models, you will need to obtain an allocation of unique product IDs from us. You can do this by emailing us at [email protected]. We will supply you with a base value from which to allocate Product IDs, and a product key file that enables these IDs for your copy of Proteus VSM.
How a Model is Authorized
In order to receive service from the simulator, a model must issue a valid authorization request as soon as it is constructed. It does this using theILICENCESERVER::authorizefunction which takes a Product ID as its single argument. The Licence Server examines the set of installed Product Keys and will authorize the model only if an appropriate key is present. If the model fails to authorize, the ILICENCESERVER::authorizefunction returns FALSE, and the model object will not receive any further calls from the simulator.
Typically, the model constructor code will read as follows:
extern "C"
{ ISPICEMODEL * _export createspicemodel (CHAR *dvc, ILICENCESERVER *ils) { ISPICEMODEL *newmodel = new MYMODEL (dvc);
ils->authorize(MY_PRODUCT_ID);
return newmodel;
} }
In some cases it is more appropriate to pass the ILICENCESERVER object to the model class constructor itself, especially if the model supports bothbatch modeandinteractivesimulations.
Overview
The Graphical Modelling Interface consists of twointerface classes.
• ClassICOMPONENTrepresents an Active Component object within ISIS and provides services which allow a VSM model to draw on the schematic and interact with the user.
• ClassIACTIVEMODELprovides a base class from which to derive your VSM graphical models.
You are required to implement functions for drawing the parent component on the schematic, and for responding to mouse and keyboard events if appropriate.
These two classes interact with ISIS, not PROSPICE and function calls to them take place at theframe rate- typically 20Hz.
Graphical Functionality
The VSM API provides you with three levels of functionality for rendering component graphics.
• Active Component paradigm. This scheme is the easiest to program but the least flexible. It makes use of sprite symbols which may be drawn within ISIS and basically allows a VSM model to select which sprite(s) are drawn at any particular time. The position and orientation of the sprite symbols relative to the component's origin may also be specified, and this allows rotary elements such as meter pointers and motor armatures to be rendered from a single sprite. SeeCREATING YOUR OWN ACTIVE COMPONENTSfor more information.
• Vector Graphics paradigm. This scheme offers a compromise between complexity of programming and flexibility. It allows a VSM model to draw vector graphics (lines, circles, arcs etc.) and text directly onto the schematic. The entities available map closely onto the 2D drawing elements provided by ISIS, and the API also provides access to the named graphics styles present in the schematic.
• Windows GDI paradigm. For the advanced programmer, the VSM API provides a means to render the component graphics using the Windows GDI. This approach allows you to do anything that is possible within Windows, and in particular allows you to use make use of bitmaps. Our LCD display model uses this approach.
You should be aware that models written using this approach will not port easily to other operating systems, should we choose to release VSM on other platforms.
Co-ordinate System
A number of the API functions take co-ordinate parameters. For example,ICOMPONENT::drawline takes four integers which represent the start and endpoints of the line. These co-ordinates are always relative to the origin of the component on the schematic, and will be mapped by the orientation of the component before being applied to the screen.
By default, the units are defined in terms of 1000 pixels per world inch. In other words, a value of 1000 in model co-ordinates will translate to a distance of 1 inch in the co-ordinate space of the schematic.
This scaling can be changed using theICOMPONENT::setdrawscalefunction.