Conference kepnut::euclid

17.0. "Boxboro Euclid Naming Conventions" by CUBICB::BARKER () Wed Aug 02 1989 14:34

SUBJECT: Boxboro euclid naming conventions and documentation control


	In order to control our Euclid objects and data bases
	better in a production [ real parts that product gets
	built from ] environment we need to define a set of ground
	rules.

	In Boxboro we plan to do the following :

	3 Data Base areas or central zones :


	1: Concept and training area - current EUC21DB.DIR;
	   Use what ever project- subproject-user name  and . BDU 
	   naming conventions that makes sense for the specific effort. 
	   No change in how the area is being run .
		
	
	2:  Development area - all object are associated with 
	    DEC part number .

	 2.1:   .BDU files will contain DEC part number consisting of

	     	Part Class - Part Basic - Part Variation [ if needed ]

		These will be mapped thru the zone table to project,
		subprojects with a different naming convention.	    


	2.2:	Project - Subproject - User Name	

		Project will consist of :

			Project Name - Responsible Group - Responsible Person
		
		example  RIGEL_ENG_RO

			 RIGEL_MFG_MH

		Subproject will consist of :

			Part Class - Part Basic - Part Variation [ if needed ]

		User name will consist of the following :

			Part Revision level held to 4 characters per DEC std 12
				
			Design group access name to get to names that
			have no principle access only external access.
			
			A scratch user name to do work in like mold 
			technology that generates a lot in intermediate
			results that final objects will be copied from to a 
			revision user name when complete.
			
	3:	World accessible area :

		Will only contain  .BDU files which are read only. The 
		central zone will be locked and unlocked by the 
		documentation coordinator to add information .

		The naming convention will be the same as the project
		work area.

		


    Object naming convention :

	The first 2 characters describe the type of object :

	EXAMPLE: SHEET METAL PART WOULD STORED AS SMXXXXXXXX.

		PLASTIC PART		PP
		SHEET METAL PART	SM
		SURFACE PART		SR
		SOLID PART		SL
		DRAWINGS
			ASSEMBLY	DA
			DETAIL PART	DP
	
		ASSEMBLY MODEL		AM
		CUT TOOL		CT
		FUSE PART		FP
		PERF			PF
		POLY LINE		PL
		FIG LINE		FL
		STD PART		ST


	The last 8 characters spaces would be used for a simple
	part description :

	EXAMPLE:  SM-BRACKET


	A more detailed description may be put into the comment area
	and stored with the geometry.

    Control -

	When a DEC part number is pulled the .BDU file and the project,
	subproject and a user name will be generated  with principal 
	connection rights in the development area :

	When a revision of a part is distributed and the rev frozen
	the principle connection to that project-subproject-user name
	will be replaced with external connection only rights. Any
	further access will be indirect [ read only ] from  the 
	project-subproject-group user name effectively write locking
	the objects. 

   External References

	There shall be no .BIS external references between data bases
	[ zones , .BDU files ] any objects needed will be copied by the 
	Euclid administrator to the data base where needed. This will allow
	for ease of moving part around and into standard zones. This 
	insures that all part information is complete in one data base
	and minimizes the possibility of data corruption.


	It is recommended that there be no .BIS references between
	user names [ revisions ] . And that the information be copied
	over . We will have to try this one to see how it works.


   System management:

	We plan to write some simple Fortran programs that use the
	databse management programing utilities to simplify the above
	process and minimize the need to use INITDB , CENTDB , EXTENDB
	and PROGDB. We plan to have our documentation coordinator handle
	most of the data base management chores thru the use of canned
	Fortran routines.