The purpose of the tools provided is to allow the programmer (or, more likely, the system architect) to auto-generate much of the code necessary for handling the communications pathways, between a host application and the CryptoServer module.
The architect starts with an idea of what data needs to be transmitted, and in what order. From that, a pattern can be derived.
The tools will "compile" the pattern, and from that generate artifacts and code based on supplied templates, for both the HSM custom firmware module, *and* the host. This includes things like the C cmd struct (for the SFC '\ext' methods), additional boiler-plate code around the C cmd struct, artifacts that provide best-practice serialization/deserialization, test code and example usage, in different programming languages and for different platforms.
It is assumed that certain of the output from the tooling will need to be merged into other files. An eventual goal is to provide an input configuration file that defines all patterns, symbol names, sub-function method information for an entire module, and therefrom auto-generate the complete structure (as if this were UML-defined). Indeed, this would allow the use of UMLbased tooling to provide additional levels of control and code generation.
For the below discussion, access to the Utimaco CryptoServer SDK is assumed. It will be useful to have access to the SDK/doc/mdl_CMDS.pdf (where the documentation for cmds_scanf is found, where the pattern structure is defined), and the example SDK/cs2/mdl/ exmp module and its src directory, to compare the output of the tools to what is found in that module in the SDK.