{des1:0} The purpose of this chapter is to define what cschem is, what major components it contains and how these components are interacting with the user and 3rd party software. This chapter provides a low resolution system map.
{des1:1} Cschem is a system for storing, displaying, editing, transforming (importing, exporting, filtering, generating, etc.) schematics data.
{des1:2} Schematics data is the logical schematics of a system, describing a system on an abstract level, optionally with directives, hints, suggestions or recommendations on the physical implementations/properties.
{des1:3} More specifically, cschem operates on projects. A project is either a single schematics page or cosists of a project file and multiple schematic pages and/or data files.
{des1:4} A typical example is an electric schematics. While cschem is not limited to electronics, this design document will use electronics in most of the examples.
{des1:5} Example: when used with electronics, cschem's role is to handle the schematics drawing, which specifies the components and their logical connections. The schematics is typically the main source for other processes, such as simulation, PCB layout, part purchase, etc.
{des1:6} This flexibility is achieved by attaching attributes to every object type in the data model. Attributes are simple, typically user defined key=value fields. Various tools in the toolchain may read and write different set of attributes. The meaning of most attributes is defined only by conventions. More about attributes can be found in chapter 4.
{des1:7} When the above concepts are implemented as a software package, called "a cschem implementation" or "a cschem package". The official implementation of the cschem concept is sch-rnd. Alternative implementations of the same concepts may exist. These implementations must be compatible on the conceptual level but might be incompatible in implementation details (including file formats).
{des1:8} The official implementation is a small, flexible, portable, modular, extensible set of tools. This chapter describes some of the implementation details of the official package. These implementation details should not affect other implementations.
{des1:9} sch-rnd consists of two major components: frontend and engine. Both components are defined as a group of smaller modules.
{des1:22} (Note: the above diagram does not contain every single subcomponent and plugin, it rather illustrates the main groups. Later chapters will enumerate subcomponents and describe them in detail.)
The job of the engine is to:
The job of the frontend is to:
{des1:15} Majority of the functionality the engine provides is implemented in modules, which are replaceable plugins. There are typical ways a module behaves:
{des1:20} The current project loaded will determine which modules should be active. For example there might be multiple implementations of DRC or slotting; each implementation would have an unique name and API version; the project would contain requirements and recommendations as of what modules are needed for proper operation, including which slotting plugin (if any). This is called the project's module dependency list.