Context<\/h2>\n
To answer the question ‘What is a System?’ you first need to understand your context. When you get down to the ‘atomic’ level for your component parts you’re unlikely to model them any further. A local authority may want to model their transport system. This may include vehicles, termini, and ticketing systems. Whilst their model may include the external specifications of a bus (in terms of weight and width) to plan a terminal, they are unlikely to care whether the bus electrical operates on 24v or 48v batteries.\u00a0 Unless they have to supply charging points at the depots. The tram’s external specification would again include width, height and mass, but it is very likely that the authority would need to know the electrical operation characteristics in their model if they are responsible for the track.<\/p>\n The bus manufacturer is not really interested in how the local authority terminal looks or operates. However, they may have design constraints for the width or length imposed by their customer. Being able to identify these parameters in their design will help them design any modifications needed to meet the requirements. Some times there is need for shared information. The ticketing system may be supplied by a third party, both the council and the bus vendor will be interested as part of that system will fall within their responsibility. Ticket sales at the terminal, ticket machines fitted on the bus. The bus manufacturer will undoubtedly model their vehicle, there will be detail plans of what connects to what and what operational parameters are needed for each. In this way if a new component is introduced, it is easier to see the impact. The new air conditioning unit needs 48v supply, the bus currently uses 24v how do we assess the impact and know what is dependent on the current voltage line?<\/p>\n Whether a system, or sub-system is worth modelling heavily depends on your position in the project chain. Deciding whether this is ‘atomic’ level for you is very dependent on your industry. Assessment should be made as to\u00a0 the likelihood that parameters of the component may affect higher level systems. The likelihood of whether a subsystem is going to be re-used in a number of different high level systems, and whether stakeholder or external constraints need to be considered.<\/p>\n If you make capacitors, you’ll have specifications for the capacitor, it’s voltage, capacitance, temperature range and so on. However, there is not much you can model at this level. If you also make wire wound inductors, then it will have similar specifications. However, as soon as they are linked together forming an LC oscillator, you have a system. There are two components who’s characteristics interact. If the LC sub-system is being supplied then the voltage at which it is safe to operate will be dictated by the components within. In this case specifying the inductor and capacitor as blocks with characteristics that form the internals of the oscillator will have a benefit in future design or specifying the operation of the sub-assembly supplied to onward customers. As the vehicle parts designer wanting to make a turning indicator unit, whether the oscillator is LC, RC and Transistor or Op-Amp is of little concern as long as the voltage, current and timing are correct. The oscillator would therefore be the atomic level here. The bus designer is not worried about the indicator unit design as long as the brightness and timing meet regulations and the longevity and power consumption are within performance parameters. They would have no interest in modelling the oscillator.<\/p>\n The fact that your model contains detailed information of the interconnections, parameters and ranges of your atomic components makes querying your model to analyse change much easier. Being able to identify all components that are expecting the same power will aid a designer in assessing the impact or running a different voltage.<\/p>\n Pretty much any system can be modelled. Software was maybe the original stable from which many modelling techniques originated, there is a need to define at what point each module interacts with the other modules. The depth to which the functions are modelled will again depend on the context. There would be no point modelling the printer driver in the system beyond the interface, if that driver is purchased along with the printer hardware. Library functions may be modelled in their own right, but the higher level designer will reference them as white or black boxes.<\/p>\n No one model has to contain everything. The passenger movements, purchases modelled as use cases. The hardware components forming the bus. The sub components forming the indicators. The software controlling the ticket system are all separate systems working as a whole.<\/p>\n <\/p>\n![\"illustration](\"https:\/\/www.threesl.com\/blog\/wp-content\/uploads\/2017\/12\/bus_components-1.png\")
<\/a>Should I model X?<\/h2>\n
<\/a>Model Benefits<\/h3>\n
<\/a>Can you model anything?<\/h2>\n