UK SMARTWARE USER GROUP, May 1995

The Avon & Somerset Constabulary is situated on the banks of the river Severn, and borders Gloucestershire, Devon and Cornwall, Wiltshire and Dorset. The force employs over 5000 civilian and police staff. It was formed in 1974 after the amalgamation of the southern part of Gloucestershire, Bristol Constabulary and the Somerset Constabulary. The current population of this policing area is approximately 1.447 million people, and is a mixture of urban, and rural environments. The force is broken down into 11 districts, each of which has a responsibility for recording and monitoring crime on their respective districts. In addition to this the crimes and statistics are collated centrally.

The most recent statistics based on the period 01/04/93 - 31/03/94 showed that there were 20,679 incidents per 100 officers during the year. The national average is 14,611 incidents per 100 officers. These figures demonstrate that the officers of Avon & Somerset are busier than any of the big metropolitan police forces, including London. During 1994 there were 165,902 crimes recorded in the force. This represents 115 crimes for every 1000 of the local population. Although this is high it represents a 5% reduction over 1993.

Police forces, throughout the country are required to submit monthly statistics for recorded and detected crime rates to the Home Office. Up until 1992 the statistics for Avon & Somerset Constabulary were produced by Somerset County Council on a contract basis. There were a number of problems with the system. Time delay between sending the information (by post) and the subsequent entry of this information into the computer system based at Taunton was just one. A remote computer terminal was based at the force statistics department in Bristol for analysis. Most of the statistics were still produced by hand. This process was not satisfactory. The force awaited the introduction of "Project 7", a forcewide UNIX based network system to handle crime recording.

Unfortunately the implementation date of "Project 7" has been deferred, consequently an alternative system was sought. In early 1992 a Home Office based Crime Analysis Package (CAP) was used on some districts, but there were shortcomings in this Lotus 1-2-3 based system - it was not a database in the true meaning of the word. Also at about this time a number of officers with experience of Smartware began developing a system using this.

In January 1993 Superintendent Bill DAVIES was tasked with developing a standard forcewide system. He put together a small team consisting working from Trinity Road police station, St. Pauls, Bristol. Over a period of 6 months the first crime management system was developed. The initial system was installed on Districts in July, and a similar system was installed in the statistics by August. The data from districts was downloaded twice a month onto floppy disk and forwarded by internal post to the statistics department for central collation and analysis. This system was very successful. It enabled crimes to be analysed locally finding patterns and trends previously hidden in mountains of paper were uncovered. The specification of the equipment used did curtail the original system design. The 386 computer only allowed one 'year of crime' to be stored in separate 'monthly' databases.

The system uses all modules of Smartware other than the communications module and is tightly linked by the programming language. The system is totally menu driven, and uses a couple of functions which provide the '3D Shadowed' appearance.

Although most of the facilities are menu driven, Smartware can be accessed from these menus to enable where more experienced users to gain further benefits. The system is password protected. Different levels of access are granted to new users depending on their knowledge and job profile.

The system has led to the creation of a new job on each district, that of Crime Analysis Officer. Armed with Smartware and access to our intelligence system (also written in Smartware) the analyst's now have powerful computerised tools at their disposal with a view to assisting the operational police officer to carry out his role more effectively.

May 1995.

SYSTEM CONFIGURATION Each district has 3 computers, a minimum of 2 486 DX2 66 PC'S running DOS 6.2, and Smartware V1.51, a third machine is 486 based. One or two of the busier districts also use a 386 based processor for inputting. The machines are linked in a Local Area Network using Novell Personal Netware in a peer to peer configuration. Printing is carried out via a LaserJet III or 4 printer. Each district is modem linked to the statistics department and Force Intelligence Bureau computers. Remote troubleshooting and training is provided by the development team via PC Anywhere V4.5. The below diagram explains this in further detail.

GENERAL OVERVIEW OF THE SYSTEM
To actually use the system a person has to have a valid password. Passwords are stored in a separate encrypted database which is also password protected. The password is supplied by the CMS (Crime Management System) program which then waits for the user to enter their identification number and password. A DATA-FIND is carried out on the entered identification number and after finding this number the password is checked. Three attempts are allowed to enter a password. After the third unsuccessful attempt the system shuts down. Each attempt at entry is stored along with the date and time in another database, ACTIVITY. A valid password entry loads the crime databases and presents the users with the main menu. Details of who is logged on are retained in public variables and throughout the use of the system. Also stored is the level of access granted, an additional field in the password record. Access level affects the way in which the system can be used, and the facilities available to an individual. Any record amendments or additions record the identification number of the current user in a calculated field on the second page of the crime record [BY].

The user, subject to access level is free to continue using the system. Following completion of their usage they can 'log off' just by quitting, and the time and date is again stored against their 'log on' record in the ACTIVITY database.

DATABASES USED
ACTIVITY
Records details of who is using the system, together with the time and date a session starts, and the time and date the session ends. All failed accesses are also recorded for data protection purposes.

CRIME
The main crime database is where most of the work takes place. Details are taken from a crime report which is, completed when a police constable attends the scene of a crime, or when a crime is reported by telephone.

PASSWORD
Details of all persons who are authorised to use the system, along with their passwords, and the access level they have been granted.

MBEAT
All valid beat codes and locations for a given district, which enables some validation of records at the input stage.

MOFFEN
Home office classification codes for all recordable crime offences, along with the text of the offence heading.

GAZETTEER
A full list of all locations within our force area. This enables staff in different parts of the force area to ascertain where a particular place is, and which district is responsible for it.

Only the crime, mbeat and moffen databases are linked. Entering a crime record requires a [BEAT] to be entered. A valid beat returns the name of the beat to the [AREA] field from the linked mbeat database. The [HO-CLASS] entry returns the text of the classification code entered from the moffen database. Both of these fields are mandatory. To ensure that a valid beat code or offence code is entered a jump rule is established in both the returned fields, i.e. [AREA], and [OFFENCE], the rule ISBLANK([]). This triggers the jump to the appropriate field, either [BEAT], in the case of an invalid beat, or [HO-CLASS] in the case of an invalid classification code.

CRIME COMPARISON This graph plots three chosen home office classifications across the period of a month. This is a useful tool when trying to correlate the relationship between different types of crime. The 'x' axis is always 31 days, and as such any periods that are less than a month do not fill the graph fully to the right side. The source of the data is a crosstab, which has a formula for each day of the month, and a count summary.

CRIME POTENTIAL To the left is a graph which basically shows when crimes overlap. This caused a few headaches because there appeared to be now way that Smartware could handle 'between times', and as such this is a 'programmed solution'. The graph is used to 'target certain times' when crime activity appears to be at it's peak.

CRIME POTENTIAL OVERVIEW
When crimes are entered there are fields for date and time from, and date and time to. These are the times that a victim of crime believes an offence took place. These times are not of much use on their own, but the times between, combined with the days are. The week is broken down into 168 hours, starting at 0001 on a Monday, until 2359 on a Sunday. Crimes that happen over four days, and with 'missing' information are queried out beforehand. Each crime is then examined in turn and the 'hours it covers' are inserted into the appropriate elements of the 168 item array. The logic for crimes that happened between times, is that the crime 'could have happened' at any of the times in between the times specified, so therefore each hour element gets 1 point added. This is all well and good but is not a true representation, so the data is further 'improved'. For example a crime that happened at a time is accurate, and is inserted into the correct array element. A crime that occurred over a 16 hour period is not so accurate. In the latter case, one sixteenth would be added to each array element for this 16 hour period, the longer the time period the smaller the fraction added to each element. The effect of this process is to produce a much sharper graph.

SWITCHING MODULES
One annoying aspect of Smartware is that which occurs when changing between modules. All functions loaded in memory or from-file are lost and have to be reloaded. To get around this in each module, the first program that is run is one to reload the functions before use. A public variable 'program$' is set in the 'sending module' with the name of the program to run, and the sending program quits to the appropriate module and runs the 'function loader', which ends by calling the program named in 'program$', below is the program listing for the spreadsheet loader, 'ssload.pf1'. This additionally changes to draft mode printing.

DRAWING FUNCTIONS
To produce the shadow effect around 'dialog boxes' and text messages some very simple functions are used, drawbox.rf3 and drawtxt.rf3.