Types of production system

The types of production system are depicted in the following image.

Image credits © Moon Rodriguez.

The types of production system are grouped under two categories viz.,

1. Intermittent production system, and
2. Continuous production system.

Now let's discuss in detail each of the above-mentioned categories.

Intermittent production system

Intermittent means something that starts (initiates) and stops (halts) at irregular (unfixed) intervals (time gaps).

In the intermittent production system, goods are produced based on customer's orders. These goods are produced on a small scale. The flow ofproduction is intermittent (irregular). In other words, the flow of production is not continuous. In this system, large varieties of products are produced. These products are of different sizes. The design of these products goes on changing. It keeps changing according to the design and size of the product. Therefore, this system is very flexible.

Following chart highlights the concept of an intermittent production system.

Following are examples on the intermittent production system. Please refer above chart while reading examples given below.

1. The work of a goldsmith is purely based on the frequency of his customer's orders. The goldsmith makes goods (ornaments) on a small-scale basis as per his customer's requirements. Here, ornaments are not done on a continuous basis.
2. Similarly, the work of a tailor is also based on the number of orders he gets from his customers. The clothes are stitched for every customer independently by the tailor as per one's measurement and size. Goods (stitched clothes) are made on a limited scale and is proportional to the number of orders received from customers. Here, stitching is not done on a continuous basis.

The features of an intermittent production system are depicted below.

The characteristics of an intermittent production system are listed as follows:

1. The flow of production is not continuous. It is intermittent.
2. Wide varieties of products are produced.
3. The volume of production is small.
4. General purpose machines are used. These machines can be used to produce different types of products.
5. The sequence of operation goes on changing as per the design of the product.
6. The quantity, size, shape, design, etc. of the product depends on the customer's orders.

The types of intermittent production system include:

1. Project production flows,
2. Jobbing production flows, and
3. Batch production flows.

Continuous production system

Continuous means something that operates constantly without any irregularities or frequent halts.

In the continuous production system, goods are produced constantly as per demand forecast. Goods are produced on a large scale for stocking and selling. They are not produced on customer's orders. Here, the inputs and outputs are standardized along with the production process and sequence.

Following chart highlights the concept of a continuous production system.

Following are examples on the continuous production system. Please refer above chart while reading examples given below.

1. The production system of a food industry is purely based on the demand forecast. Here, a large-scale production of food takes place. It is also a continuous production.
2. Similarly, the production and processing system of a fuel industry is also purely based on, demand forecast. Crude oil and other raw sources are processed continuously on a large scale to yield usable form of fuel and compensate global energy demand.

The features of a continuous production system are depicted below.

The characteristics of a continuous production system are listed as follows:

1. The flow of production is continuous. It is not intermittent.
2. The products are standardized.
3. The products are produced on predetermined quality standards.
4. The products are produced in anticipation of demand.
5. Standardized routing sheets and schedules are prepared.

The types of continuous production system include:

1. Mass production flows, and
2. Process production flows.

Types of Manufacturing Systems

Manufacturing Systems Types

Let us first look at the essential components of Manufacturing Systems:



The process of designing a manufacturing system therefore must engage upon the design of each of the above four components AND their integration.
Notice that this figure is pretty much consistent with Prof Sohlenius's architecture of Manufacturing systems, which is partially reproduced in the following figure. While the following figure implicitly assumes the important role of the human in each of the modules, I have explicitly placed it separately in the figure above, partly because it helps in highlighting the importance of planning the human aspects of the system.

(source: Lecture notes, Prof Gunnar Sohlenius)
We first look broadly at these four elements, and subsequently, we shall study each of these aspects in somewhat more detail.

Informal definitions:
Physical Systems refer to all physical aspects of a manufacturing system, including the factories, including the facilities, machines, tools etc., the raw materials, the material handling systems, the work in process, as well as the products.

The Operation refers to all aspects of decision structures that determine how the system functions. For example, does it use a Toyota style pull production, or does it depend on an MRP II system with forecasts driven production? How does the plant manager determine the size and sequence of the jobs to be done on each machine, on each day?

The Information in a manufacturing system refers to all data that will be accessed by some function/person/decision-maker/software etc., and whose value may be used deciding upon an action. Examples include design data, machine data, tool data, inventory status, process data, vendors, clients, personnel data and so on. It is likely that for any MS of reasonable complexity, one will need automated data handling facilities, e.g. a DBMS. I will also loosely include in this definition, mechanisms that are required for the flow of information, that is, Information Technology (IT). This includes communication protocols (such as MAP, TOP, ISO-OSI), etc.

Humans refers to all personnel, vendors, customers, etc. Personnel related issues include: what is the capability level of available labour, what is the working culture (1-shift, 2-shift availability), how many do we need to hire for a given MS, what is the level of training needed, what policies will lead to better working environment etc. Customers are another essential human element in the design of MS.

---

We begin the study with the physical systems. I will use the following classification of manufacturing systems, which uses the material flow type as its basis:

• Product based: These are manufacturing systems that are designed specifically for a fixed product (or product type). The underlying principles are those of interchangeability, and division of labour. These systems may be highly automated, or human-labour intensive. However, in every case, they must operate at relatively high throughput rates.
  

  Further divided into:
  
  
  
  
   Continuous production (e.g. chemicals, food processing etc.)
  
  
  
  
   Discrete part production. Further divided into:
  
    Assembly lines
  
    Transfer Lines
  
  

• Process-based: these are facilities where machines of the same type are grouped together physically. Some examples may be seen in job shops, workshops, prototype makers, tool makers.Flexible Manufacturing systems may loosely be categorized as highly automated versions of process-based systems.
• Cellular: Cells are formed using GT, and typical cells are small clusters of a mixed bunch of machines that can handle a particular family of products. Such layouts are used when the batch sizes of orders are not large, but throughput times required are lower.
• Fixed position: For single units of a large item (e.g. construction project, MTR line, ship building etc.)

The above are all the physical production systems. In addition, we shall look at material handling systems, including transportation machines and inventory handling systems.

---

Once we have a physical system all installed, we need to worry about the operational aspects. This includes, among other things, Production Control. Several important things here include:
Lot sizing;
Scheduling;
Process Planning;
When we design the physical systems, we are concerned with the capability to produce the designed part. When studying the operational aspects, we are more concerned with the efficiency at which we are working. Therefore, it is essential for us to know our goals, when we make operational decisions. Some typical descriptors used for Manufacturing Systems include:

WIP (Work in Process): The number of parts that are currently in the shop floor, either being worked upon by a machine/operator, or waiting at a buffer or in a queue.
Production rate: number of finished parts being produced by the system in unit time.
Throughput time: the time that a part spends in the system from the moment it is released from the inventory to the time it leaves the system.

Usually, we would like to make operational plans that are "good". That means we should know what we mean by "good", especially since often, different desirable objectives tend to be conflicting [which is what gave rise to teh famous saying: Good, Cheap, Fast. Pick any two.] Here are some definitions and some typical objectives:

Assume that jobs coming into the system are identified as J_i.
Due date, D_i: date when the job is expected to be completed.
Completion time, C_i: time at which J_i is completed.
Flow time, F_i: length of time J_i is in the shop.
Lateness, L_i = ( C_i - D_i).
Tardiness, T_i = max( 0, L_i).

Typical objectives include: minimize average flow time, minimize number of tardy jobs, minimize average tardiness, minimize the makespan (makespan = time to complete all the jobs), minimize the maximum tardiness etc.

Once we define our goals, we can test out which operational method (heuristic) gives us the best performance in order to achieve our goal(s). We can do so by actually testing our operation plans on the shop floor, or we may study their perfomance using models. A good designer will model his MS before implementing it: it is almost always cheaper to do so!

Therefore, we shall take a brief look at methods used to model manufacturing systems: in particular, simple mathematical models, and simulation.

Why are operational performance tests important to MS Design ?
- since they can give a good estimate of potential bottlenecks, and also be used to refine designs before implementation.

---

In the Human part, we will look at two important aspects:

• What the are conditions under which the workers perform the best? How can this information be used to design the work pattern of workers, and working system of manufacturing systems (team oriented systems)?
• Why is the customer an important part of the operations of the MS ? What implications does this participation of the customer have on the operation and organisation of the MS.

what is overloading and overriding

Overloading is defining functions that have similar signatures, yet have different parameters. 

Overriding is only pertinent to derived classes, where the parent class has defined a method and the derived class wishes to override that function.

Overriding	Overloading
Methods name and signatures must be same.	Having same method name with different Signatures.
Overriding is the concept of runtime polymorphism	Overloading is the concept of compile time polymorphism
When a function of base class is re-defined in the derived class called as Overriding	Two functions having same name and return type, but with different type and/or number of arguments is called as Overloading
It needs inheritance.	It doesn't need inheritance.
Method should have same data type.	Method can have different data types
Method should be public.	Method can be different access specifies

Example

Overriding

public class MyBaseClass

{

    public virtual void MyMethod()

    {

        Console.Write("My BaseClass Method");

    }

}

public class MyDerivedClass : MyBaseClass

{

    public override void MyMethod()

    {

        Console.Write("My DerivedClass Method");

    }

}

Overloading 

int add(int a, int b)

int add(float a , float b)

How to find 2nd and nth highest salary in sql

To Find Max salary

select MAX(Salary) from Employee;

finding the 2nd highest salary in SQL

SELECT MAX(Salary) FROM Employee
WHERE Salary NOT IN (SELECT MAX(Salary) FROM Employee )

An alternative solution using the not equals SQL operator

select MAX(Salary) from Employee
WHERE Salary <> (select MAX(Salary) from Employee )

How would you write a SQL query to find the Nth highest salary?

Here we will present one possible answer to finding the nth highest salary first, and the explanation of that answer after since it’s actually easier to understand that way. Note that the first answer we present is actually not optimal from a performance standpoint since it uses a subquery, but we think that it will be interesting for you to learn about because you might just learn something new about SQL. If you want to see the more optimal solutions first, you can skip down to the sections that says “Find the nth highest salary without a subquery” instead.

The SQL below will give you the correct answer – but you will have to plug in an actual value for N of course. This SQL to find the Nth highest salary should work in SQL Server, MySQL, DB2, Oracle, Teradata, and almost any other RDBMS:

SELECT * /*This is the outer query part */
FROM Employee Emp1
WHERE (N-1) = ( /* Subquery starts here */
SELECT COUNT(DISTINCT(Emp2.Salary))
FROM Employee Emp2
WHERE Emp2.Salary > Emp1.Salary)

Finding nth highest salary example and explanation

Let’s step through an actual example to see how the query above will actually execute step by step. Suppose we are looking for the 2nd highest Salary value in our table above, so our N is 2. This means that the query will look like this:

SELECT *
FROM Employee Emp1
WHERE (1) = (
SELECT COUNT(DISTINCT(Emp2.Salary))
FROM Employee Emp2
WHERE Emp2.Salary > Emp1.Salary)

You can probably see that Emp1 and Emp2 are just aliases for the same Employee table – it’s like we just created 2 separate clones of the Employee table and gave them different names.

State Management in ASP.NET

A new instance of the Web page class is created each time the page is posted to the server. In traditional Web programming, this would typically mean that all information associated with the page and the controls on the page would be lost with each round trip. For example, if a user enters information into a text box, that information would be lost in the round trip from the browser or client device to the server.

To overcome this inherent limitation of traditional Web programming, ASP.NET includes several options that help you preserve data on both a per-page basis and an application-wide basis. These features are as follows:

• View state
• Control state
• Hidden fields
• Cookies
• Query strings
• Application state
• Session state
• Profile Properties

View state, control state, hidden fields, cookies, and query strings all involve storing data on the client in various ways. However, application state, session state, and profile properties all store data in memory on the server. Each option has distinct advantages and disadvantages, depending on the scenario.

Client-Based State Management Options

---

The following sections describe options for state management that involve storing information either in the page or on the client computer. For these options, no information is maintained on the server between round trips.

View State

The ViewState property provides a dictionary object for retaining values between multiple requests for the same page. This is the default method that the page uses to preserve page and control property values between round trips.

When the page is processed, the current state of the page and controls is hashed into a string and saved in the page as a hidden field, or multiple hidden fields if the amount of data stored in the ViewState property exceeds the specified value in the MaxPageStateFieldLength property. When the page is posted back to the server, the page parses the view-state string at page initialization and restores property information in the page.

You can store values in view state as well. For more information on using View State, see ASP.NET View State Overview. For recommendations about when you should use view state, see ASP.NET State Management Recommendations.

Control State

Sometimes you need to store control-state data in order for a control to work properly. For example, if you have written a custom control that has different tabs that show different information, in order for that control to work as expected, the control needs to know which tab is selected between round trips. The ViewState property can be used for this purpose, but view state can be turned off at a page level by developers, effectively breaking your control. To solve this, the ASP.NET page framework exposes a feature in ASP.NET called control state.

The ControlState property allows you to persist property information that is specific to a control and cannot be turned off like the ViewState property.

Hidden Fields

ASP.NET allows you to store information in a HiddenField control, which renders as a standard HTML hidden field. A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information that you want to store directly in the page.

A HiddenField control stores a single variable in its Value property and must be explicitly added to the page. For more information, see HiddenField Web Server Control Overview.

In order for hidden-field values to be available during page processing, you must submit the page using an HTTP POST command. If you use hidden fields and a page is processed in response to a link or an HTTP GET command, the hidden fields will not be available. For usage recommendations, see ASP.NET State Management Recommendations.

Cookies

A cookie is a small amount of data that is stored either in a text file on the client file system or in-memory in the client browser session. It contains site-specific information that the server sends to the client along with page output. Cookies can be temporary (with specific expiration times and dates) or persistent.

You can use cookies to store information about a particular client, session, or application. The cookies are saved on the client device, and when the browser requests a page, the client sends the information in the cookie along with the request information. The server can read the cookie and extract its value. A typical use is to store a token (perhaps encrypted) indicating that the user has already been authenticated in your application.

For more information about using cookies, see Cookies and ASP.NET State Management Recommendations.

Query Strings

A query string is information that is appended to the end of a page URL. A typical query string might look like the following example:

http://www.contoso.com/listwidgets.aspx?category=basic&price=100

In the URL path above, the query string starts with a question mark (?) and includes two attribute/value pairs, one called "category" and the other called "price."

Query strings provide a simple but limited way to maintain state information. For example, they are an easy way to pass information from one page to another, such as passing a product number from one page to another page where it will be processed. However, some browsers and client devices impose a 2083-character limit on the length of the URL.

In order for query string values to be available during page processing, you must submit the page using an HTTP GET command. That is, you cannot take advantage of a query string if a page is processed in response to an HTTP POST command. For usage recommendations, see ASP.NET State Management Recommendations.

Server-Based State Management Options

---

ASP.NET offers you a variety of ways to maintain state information on the server, rather than persisting information on the client. With server-based state management, you can decrease the amount of information sent to the client in order to preserve state, however it can use costly resources on the server. The following sections describe three server-based state management features: application state, session state, and profile properties.

Application State

ASP.NET allows you to save values using application state — which is an instance of the HttpApplicationState class — for each active Web application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus, application state is useful for storing information that needs to be maintained between server round trips and between requests for pages. For more information, see ASP.NET Application State Overview.

Application state is stored in a key/value dictionary that is created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests.

Once you add your application-specific information to application state, the server manages it. For usage recommendations, see ASP.NET State Management Recommendations.

Session State

ASP.NET allows you to save values by using session state — which is an instance of the HttpSessionState class — for each active Web-application session. For an overview, see ASP.NET Session State Overview.

Session state is similar to application state, except that it is scoped to the current browser session. If different users are using your application, each user session will have a different session state. In addition, if a user leaves your application and then returns later, the second user session will have a different session state from the first.

Session state is structured as a key/value dictionary for storing session-specific information that needs to be maintained between server round trips and between requests for pages. For more information, see ASP.NET Session State Overview.

You can use session state to accomplish the following tasks:

• Uniquely identify browser or client-device requests and map them to an individual session instance on the server.
• Store session-specific data on the server for use across multiple browser or client-device requests within the same session.
• Raise appropriate session management events. In addition, you can write application code leveraging these events.

Once you add your application-specific information to session state, the server manages this object. Depending on which options you specify, session information can be stored in cookies, on an out-of-process server, or on a computer running Microsoft SQL Server. For usage recommendations, see ASP.NET State Management Recommendations.

Profile Properties

ASP.NET provides a feature called profile properties, which allows you to store user-specific data. This feature is similar to session state, except that the profile data is not lost when a user's session expires. The profile-properties feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user. The ASP.NET profile allows you to easily manage user information without requiring you to create and maintain your own database. In addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in your application. You can store objects of any type in the profile. The ASP.NET profile feature provides a generic storage system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.

To use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a custom format and to a custom storage mechanism such as an XML file, or even to a web service.

Because data that is placed in profile properties is not stored in application memory, it is preserved through Internet Information Services (IIS) restarts and worker-process restarts without losing data. Additionally, profile properties can be persisted across multiple processes such as in a Web farm or a Web garden. For more information, seeASP.NET Profile Properties Overview.

Use of @@ symbol in sql

Syntax

@@{url | file_name[.ext] } [arg...]

Runs a script. This command is almost identical to the @ ("at" sign) command. When running nested scripts it looks for nested scripts in the same path or urlas the calling script. Only the url form is supported in iSQL*Plus. The @@ command functions similarly to @ and START.

Terms

url

Specifies the Uniform Resource Locator of a script to run on the specified web server. SQL*Plus supports HTTP and FTP protocols, but not HTTPS. HTTP authentication in the form http://username:password@machine_name.domain... is not supported in this release.

file_name[.ext]

Represents the nested script you wish to run. If you omit ext, SQL*Plus assumes the default command-file extension (normally SQL). For information on changing the default extension, see SET SUF[FIX] {SQL | text}.

When you enter @@file_name.ext from within a script, SQL*Plus runs file_name.ext from the same directory as the script.

When you enter @@file_name.ext interactively, SQL*Plus runs file_name.ext from the current working directory or from the same url as the script from which it was called. If SQL*Plus does not find the file, it searches a system-dependent path to find the file. Some operating systems may not support the path search. See the platform-specific Oracle documentation provided for your operating system for specific information related to your operating system environment.

arg...

Represent data items you wish to pass to parameters in the script. If you enter one or more arguments, SQL*Plus substitutes the values into the parameters(&1, &2, and so forth) in the script. The first argument replaces each occurrence of &1, the second replaces each occurrence of &2, and so forth.

The @@ command defines the parameters with the values given by the arguments. If you run the script again in this session, you can enter new arguments or omit the arguments to use the current values. For more information on using parameters, see Substitution Variables in iSQL*Plus.

Usage

All previous settings like COLUMN command settings stay in effect when the script starts. If the script changes any setting, the new value stays in effect after the script has finished.

You can include in a script any command you would normally enter interactively (typically, SQL or SQL*Plus commands).

If the START command is disabled (see "Disabling SQL*Plus, SQL, and PL/SQL Commands"), this will also disable the @@ command. For more information, see the SPOOL command.

SQL*Plus removes the SQLTERMINATOR (a semicolon by default) before the @@ command is issued. A workaround for this is to add another SQLTERMINATOR. See SET SQLT[ERMINATOR] {; | c | ON | OFF} for more information.

Examples

Suppose that you have the following script named PRINTRPT:

SELECT DEPARTMENT_ID, CITY FROM EMP_DETAILS_VIEW WHERE SALARY>12000;@EMPRPT.SQL@@ WKRPT.SQL

When you START PRINTRPT and it reaches the @ command, it looks for the script named EMPRPT in the current working directory and runs it. When PRINTRPT reaches the @@ command, it looks for the script named WKRPT in the same path as PRINTRPT and runs it.

Suppose that the same script PRINTRPT was located on a web server and you ran it with START HTTP://machine_name.domain:port/PRINTRPT. When it reaches the @ command, it looks for the script named EMPRPT in the current working directory and runs it. When PRINTRPT reaches the @@ command, it looks for the script named WKRPT in the same url as PRINTRPT, HTTP://machine_name.domain:port/WKRPT.SQL and runs it.

What are cluster aware and instance aware services?

Cluster Aware: which get failover like SQL Server, SQL Agent, MSDTC.

Instance Aware: SSIS, SSAS, SSRS, SQL Agent, SQL Server

Difference between Viewbag and Viewdata in ASP.NET MVC

Both are used to pass the data from controllers to views. 
The difference between Viewbag and Viewdata in ASP.NET MVC is explained below: 

View Data: 
In this, objects are accessible using strings as keys. 

Example: 

In the Controller: 
public ActionResult Index() 
{ 
var softwareDevelopers = new List<string> 
{ 
"Brendan Enrick", 
"Kevin Kuebler", 
"Todd Ropog" 
}; 
ViewData["softwareDevelopers"] = softwareDevelopers; 
return View(); 
} 

In the View: 
<ul> 
@foreach (var developer in (List<string>)ViewData["softwareDevelopers"]) 
{ 
<li> 
@developer 
</li> 
} 
</ul> 

An important note is that when we go to use out object on the view that we have to cast it since the ViewData is storing everything as object. 

View Bag: 
It will allow the objectto dynamically have the properties add to it. 

Example: 

In the Controller: 
public ActionResult Index() 
{ 
var softwareDevelopers = new List<string> 
{ 
"Brendan Enrick", 
"Kevin Kuebler", 
"Todd Ropog" 
}; 
ViewBag.softwareDevelopers = softwareDevelopers; 
return View(); 
} 

In the View: 
<ul> 
@foreach (var developer in ViewBag.softwareDevelopers) 
{ 
<li> 
@developer 
</li> 
} 
</ul> 

An important point to note is that there is no need to cast our object when using the ViewBag. This is because the dynamic we used lets us know the type.

What is Razor View Engine?

Razor is the first major update to render HTML in MVC3. Razor was designed specifically as a view engine syntax. It has one main focus: code-focused templating for HTML generation. Here’s how that same markup would be generated using Razor:

@model MvcMusicStore.Models.Genre
@{
ViewBag.Title = "Browse Albums";
}
<div class="genre">
<h3><em>@Model.Name</em> Albums</h3>
<ul id="album-list">
@foreach (var album in Model.Albums)
{
<li>
<a href="@Url.Action("Details", new { id = album.AlbumId })">
<img alt="@album.Title" src="@album.AlbumArtUrl" />
<span>@album.Title</span>
</a>
</li>
}
</ul>
</div>
The Razor syntax is easier to type, and easier to
read. Razor doesn’t have the XML-like heavy syntax. of the Web Forms view
engine.