kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26914
Re: Ideas for a lightweight KiCad PDM
On Tue, Dec 6, 2016 at 4:39 PM, Clemens Koller <cko@xxxxxxxxx> wrote:
> Hello, Kevin!
>
> I fully support your ideas. In a commercial environment, a proper PDM
including version management and documentation is mandatory to be able to
deliver a product where you can realize a traceability down to the date
code of a component once your design is manufactured.
>
> But since all projects / infrastructures / companies differ, it is
propably not a good idea to hard code some workflow into the design tool
(KiCad) and expect a one fits all approach.
>
> I have sort of a wishlist which would allow me to interface KiCad to my
existing infrastucture and solve some issues which cost me a lot of time:
> - The library as well as all design data should be accessible
(read-writeable) like a database (ideally: while KiCad is running).
> - Everything (even every single connection in the schematics) has a
version and a (modification) timestamp and is sortable by object,
properties, version and timestamp.
> - A copy&paste (reuse) of fractions of a design should optionally include
it's objects properties, constraints, versions and history.
> - A diff and merge of parts or whole designs would improve versioning and
design-reuse a lot.
> * I would love to see forward/rewind buttons for libraries, schematics
and layout similar to browsing through the git history of a software
project 8-).
>
> For performance reasons I believe it is not a good idea to implement
design to library connectivity with links on a file-system level as it is
done by bothy commercial products quite a lot. (One horribly expensive
product seems to hold the whole design in an (optimized) database in memory
and is able to replicate the data in real-time in between several
workstations to feature "concurrent design entry" where several
people/autorouters are able to work on one design at the same time.)
>
> OT:
> I am working a lot with databases (SQL based) and several external tools
(self-written stuff + git) to manage my component library, the library
generators, as well as my local component information / stock data. I am
able to "link" a BOM written by the design tool with my component database
(+ local stock data) and then with the i.e. SAP data (+ remote stock data)
of my manufacturer to transfer my design to the assembly in an automated
way. We implemented something like a closed-loop-verification process where
I am able to read back the SAP data (maybe in the future through some
remote database interface) into my database to verify that the data will
arrive correctly at the machines. Sometimes, I'll need to update my local
data when the assembly needs a change somewhere. Since everything is a
moving target you want to freeze all the information for each manufacturing
lot / product version.
>
> These processes different a lot from one assembly house to the next one.
So, there is a cookbook of scripts tailored to each manufacturers process
with a lot of verification steps built in. There are usually no more .xls
files envolved in the whole process where busy people tend to add typos
manually without getting noticed.
>
> Regards,
>
> Clemens
>
Thanks for the feedback. I will include your these in my collection of
things to consider.
>
> On 2016-12-06 08:22, Kevin Bortis wrote:
>> Hi
>>
>> I try to figure out how it would be possible to create a central
>> storage for symbols, footprints and other design data. With central I
>> mean something like a design data server, where it is possible to
>> assign workflows with sign-offs, make proper versioning, assign order
>> numbers and define second sources. (PDM ultra light for KiCad).
>>
>> I currently work on some projects where we need to be sure that each
>> change on current products gets a proper review and documentation.
>> This always starts with a "Change Request", followed by a "Change
>> Order". To make sure everything is right, we currently use a very
>> expensive EDA suite with even more expensive PDM[2] software. Even if
>> this seems overkill for private projects, a little more lighter
>> version of this workflow makes sens for every company and even for
>> some bigger private projects. I helps to grantees some quality and
>> data integrity.
>>
>> After some analysis how KiCad does things I see some little problems.
>> The first of them is described in the following lines:
>>
>> Currently the footprint and soon[1] symbols will be assigned with a
>> "library nickname"/"symbol name" key. This is also true for the 3D
>> model inside the footprint file. At the moment this is the only
>> reference to the library. If the component in the local file storage
>> changes, the symbol/footprint gets changed immediately in the project
>> and that is exactly what I want to avoid. To make a server based
>> library, each symbol or footprint would need a unique identifier and
>> some way to define the storage location. Say instead of define
>> somelibrary/symbol1 (implicit local storage) define
>> srv://remote1/16fd2706-8baf-433b-82eb-8c7fada847da (explicit remote
>> storage) where remote1 is a configured remote storage location in the
>> app. The fully qualified address of the symbol would then be something
>> like https://myserver.local/lib/uuid/16fd2706-8baf-433b-82eb-8c7fada847da
>>
>> A second possibility would be to introduce a new file (symbol.origin)
>> in the project folder to keep track of every remote stored file.
>>
>> symbol.orign:
>> somelibrary/symbol1=remote1/16fd2706-8baf-433b-82eb-8c7fada847da
>> somelibrary/footprint2=remote1/23fd2706-3baf-223b-82eb-ef7fada847ac
>>
>> After retrival from the central storage, I would save the symbol as
>> libs/somelibrary/symbol1 locally in the project tree. This would have
>> almost no impact on the KiCad code I think. A command can be
>> implemented to verifiy data integrity by getting file hashes of each
>> component from the central server and checking if everything is in
>> sync. A second command to check if a newer version of the symbol is
>> available with the option to update it. To make this work, KiCad would
>> need to track the origin of every 3D model, symbol, footprint...
>>
>> I would appreciate if some one has some input on this topic.
>>
>> [1] https://lists.launchpad.net/kicad-developers/msg26901.html
>> [2] https://en.wikipedia.org/wiki/Product_data_management
>>
>> Regards
>> Kevin
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
References